Re: Assembly plugin issues
On 8/22/06, Owen Jacobson <[EMAIL PROTECTED]> wrote: > However I have one last thing to try: > I notice that you have two moduleSet declarations. > Can you not collapse them into one? which contains both the source and > the binary sections? > > I suspect that might be the problem. Just for grins I tried this anyways. It still duplicated the foo-1.3-SNAPSHOT part of the assembly-relative path. Does this not explain how to do what you want? http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-source-inclusion-simple.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin issues
On 8/23/06, Douglas Ferguson <[EMAIL PROTECTED]> wrote:
I am not sure I follow, dependencySet is in the assembly.xml.
Can you give an example tag you'd need to add the the xml below to get it to
exclude 1 class file that is picked up from the dependencySet below?
You don't use the dependencySet to exclude the file.
DependencySet copies existing dependencies.
What you do is you craft your assembly so that it includes or excludes
the files you want.
So in my src/main/assembly/bin.xml (which is building a binary
distribution for an artifact say my.group:mouldeA):
I have:
bin
dir
zip
true
src/main/config
config/
*
target
${artifactId}-${version}.jar
src/main/scripts/start_debug.bat
false
src/main/scripts/start.bat
false
src/main/scripts/stop.bat
false
lib
false
${artifactId}-${baseVersion}.${extension}
Here you would include all the files you want.
Or exclude them as necessary in fileSet or file declarations.
Then in my main distribution I would include this as a dependency as
per my previous mail and it will automatically be included in the
super archive as part of the dependencySet.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Assembly plugin issues
I am not sure I follow, dependencySet is in the assembly.xml. Can you give an example tag you'd need to add the the xml below to get it to exclude 1 class file that is picked up from the dependencySet below? - Original Message - From: Barrie Treloar Sent: Tue, 8/22/2006 11:54pm To: Maven Users List Subject: Re: Assembly plugin issues On 8/23/06, Douglas Ferguson <[EMAIL PROTECTED]> wrote: > When using the dependencySet, can you exclude individual class files or are > you limited to excluding specific artifacts. dependency set excludes specific dependencies. When you create your assembly that is the place to exclude any files that you don't want in your assembly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin issues
On 8/23/06, Douglas Ferguson <[EMAIL PROTECTED]> wrote: When using the dependencySet, can you exclude individual class files or are you limited to excluding specific artifacts. dependency set excludes specific dependencies. When you create your assembly that is the place to exclude any files that you don't want in your assembly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Assembly plugin issues
When using the dependencySet, can you exclude individual class files or are you
limited to excluding specific artifacts.
- Original Message -
From: Barrie Treloar
Sent: Tue, 8/22/2006 7:03pm
To: Maven Users List
Subject: Re: Assembly plugin issues
On 8/22/06, Owen Jacobson <[EMAIL PROTECTED]> wrote:
> > However I have one last thing to try:
> > I notice that you have two moduleSet declarations.
> > Can you not collapse them into one? which contains both the source and
> > the binary sections?
> >
> > I suspect that might be the problem.
>
> Just for grins I tried this anyways. It still duplicated the
> foo-1.3-SNAPSHOT part of the assembly-relative path.
As I mentioned I don't use moduleSets.
I use dependencySets and I have a module whose sole job is to pull all
the dependencies I want together to form a super-archive.
You might want to look into that instead.
Also look at the source plugin
http://maven.apache.org/plugins/maven-source-plugin/ which will build
a source archive and attach it as part of your build process. Then in
your assembly you pull in the dependency with the source classifier.
See
http://www.nabble.com/forum/ViewPost.jtp?post=5496323&framed=y
I can't find any more appropriate posts, so I'll include some more details:
My project layout is:
ROOT/
- pom.xml
- module1
- moduleN
- -build
- pom.xml
In -build/pom.xml I have:
my.group
module1Artifact
1.0-SNAPSHOT
zip
my.group
module2Artifact
1.0-SNAPSHOT
bin
zip
my.group
module3Artifact
1.0-SNAPSHOT
bin
zip
my.group
module4Artifact
1.0-SNAPSHOT
ear
So my main build collects 4 artifacts:
- a client side eclipse RCP (artifact1) as a zip
- 2 standalone applications (artifact2, artifact3) as binary builds
(these are the attached binary assemblies created when you install
artifact2 and artifact3)
- an ear file (artifact4)
My assembly in -build/src/main/assembly/bin.xml:
bin
zip
true
false
${artifactId}-${baseVersion}.${extension}
commons-beanutils:commons-beanutils
commons-beanutils:commons-beanutils-bean-collections
commons-beanutils:commons-beanutils-core
commons-collections:commons-collections
commons-configuration:commons-configuration
commons-digester:commons-digester
commons-lang:commons-lang
commons-logging:commons-logging
easyconf:easyconf
log4j:log4j
weblogic:weblogic
xstream:xstream
You need all those excludes because you dependency on the binary
artifact also depends upon the jars which get included even though
those same jars have already been included in the binary assembly.
So, by using the source jar which will install an artifact with
classified "sources" you should be able to use the above information
to craft your own assemblies to pull in the source version of your
artifact you want.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin issues
On 8/22/06, Owen Jacobson <[EMAIL PROTECTED]> wrote:
> However I have one last thing to try:
> I notice that you have two moduleSet declarations.
> Can you not collapse them into one? which contains both the source and
> the binary sections?
>
> I suspect that might be the problem.
Just for grins I tried this anyways. It still duplicated the
foo-1.3-SNAPSHOT part of the assembly-relative path.
As I mentioned I don't use moduleSets.
I use dependencySets and I have a module whose sole job is to pull all
the dependencies I want together to form a super-archive.
You might want to look into that instead.
Also look at the source plugin
http://maven.apache.org/plugins/maven-source-plugin/ which will build
a source archive and attach it as part of your build process. Then in
your assembly you pull in the dependency with the source classifier.
See
http://www.nabble.com/forum/ViewPost.jtp?post=5496323&framed=y
I can't find any more appropriate posts, so I'll include some more details:
My project layout is:
ROOT/
- pom.xml
- module1
- moduleN
- -build
- pom.xml
In -build/pom.xml I have:
my.group
module1Artifact
1.0-SNAPSHOT
zip
my.group
module2Artifact
1.0-SNAPSHOT
bin
zip
my.group
module3Artifact
1.0-SNAPSHOT
bin
zip
my.group
module4Artifact
1.0-SNAPSHOT
ear
So my main build collects 4 artifacts:
- a client side eclipse RCP (artifact1) as a zip
- 2 standalone applications (artifact2, artifact3) as binary builds
(these are the attached binary assemblies created when you install
artifact2 and artifact3)
- an ear file (artifact4)
My assembly in -build/src/main/assembly/bin.xml:
bin
zip
true
false
${artifactId}-${baseVersion}.${extension}
commons-beanutils:commons-beanutils
commons-beanutils:commons-beanutils-bean-collections
commons-beanutils:commons-beanutils-core
commons-collections:commons-collections
commons-configuration:commons-configuration
commons-digester:commons-digester
commons-lang:commons-lang
commons-logging:commons-logging
easyconf:easyconf
log4j:log4j
weblogic:weblogic
xstream:xstream
You need all those excludes because you dependency on the binary
artifact also depends upon the jars which get included even though
those same jars have already been included in the binary assembly.
So, by using the source jar which will install an artifact with
classified "sources" you should be able to use the above information
to craft your own assemblies to pull in the source version of your
artifact you want.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin issues
However I have one last thing to try: I notice that you have two moduleSet declarations. Can you not collapse them into one? which contains both the source and the binary sections? I suspect that might be the problem. Just for grins I tried this anyways. It still duplicated the foo-1.3-SNAPSHOT part of the assembly-relative path. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin issues
On 8/22/06, Barrie Treloar <[EMAIL PROTECTED]> wrote: > No love there. It still duplicates the foo-1.3-SNAPSHOT part of the > path* in the sources. Good point about not needing to name a > directory 'src' myself, though. > > At this point I'd be happy if it just put it in as > foo-1.3-SNAPSHOT/example/pom.xml etc. > > * Like this: > > ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/main/java/com/foo/examples/Example.java > ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/main/java/com/foo/examples/package-info.java > ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/pom.xml > ./foo-1.3-SNAPSHOT/foo-examples-1.3-SNAPSHOT.jar Ahh I see the problem now. You may have to file a bug report on JIRA. However I have one last thing to try: I notice that you have two moduleSet declarations. Can you not collapse them into one? which contains both the source and the binary sections? I suspect that might be the problem. No; they have differing inclusion lists. The binary one includes all the modules; the source one includes only the foo-examples module. It definitely looks like a bug, then. Ick. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin issues
No love there. It still duplicates the foo-1.3-SNAPSHOT part of the path* in the sources. Good point about not needing to name a directory 'src' myself, though. At this point I'd be happy if it just put it in as foo-1.3-SNAPSHOT/example/pom.xml etc. * Like this: ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/main/java/com/foo/examples/Example.java ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/main/java/com/foo/examples/package-info.java ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/pom.xml ./foo-1.3-SNAPSHOT/foo-examples-1.3-SNAPSHOT.jar Ahh I see the problem now. You may have to file a bug report on JIRA. However I have one last thing to try: I notice that you have two moduleSet declarations. Can you not collapse them into one? which contains both the source and the binary sections? I suspect that might be the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin issues
On 8/22/06, Barrie Treloar <[EMAIL PROTECTED]> wrote: > foo-1.2/src/com/example/Example.java [del] > > > > com.example.foo:foo-examples > > > /src > > > > I'd suggest changing the outputDirectory to be / just like it is for binaries. No love there. It still duplicates the foo-1.3-SNAPSHOT part of the path* in the sources. Good point about not needing to name a directory 'src' myself, though. At this point I'd be happy if it just put it in as foo-1.3-SNAPSHOT/example/pom.xml etc. * Like this: ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/main/java/com/foo/examples/Example.java ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/main/java/com/foo/examples/package-info.java ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/pom.xml ./foo-1.3-SNAPSHOT/foo-examples-1.3-SNAPSHOT.jar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin issues
foo-1.2/src/com/example/Example.java [del] com.example.foo:foo-examples /src I'd suggest changing the outputDirectory to be / just like it is for binaries. ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/src/main/java/foo/examples/package-info.java ./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/pom.xml Notice that the pom file is also located at src/pom.xml I don't use moduleSets so YMMV, however I think it is copying your pom as well and if you make the outputDirectory / then you will find that it is copying the files to where you expect them to go. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly plugin issues
Good evening.
I'm trying to use my root POM to build an assembly corresponding to
what my current "final" ant build generates, which has all the project
JARs as well as source to one module laid out like:
foo-1.2.zip:
foo-1.2/README
foo-1.2/foo-a-1.2.jar
foo-1.2/foo-b-1.2.jar
foo-1.2/foo-c-1.2.jar
foo-1.2/src/com/example/Example.java
I've almost got the maven assembly plugin building the right thing.
Specifically, the README and binaries show up in the right places just
fine. The source for the example, however... has some issues.
The assembly XML looks like
--- cut here ---
dir
tar.gz
zip
/
false
com.example.foo:foo-examples
/src
--- end here ---
...but the sources end up somewhere strange:
$ cd target/foo-1.3-SNAPSHOT.dir/
$ find
./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/src/main/java/foo/examples/Example.java
./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/src/main/java/foo/examples/package-info.java
./foo-1.3-SNAPSHOT/foo-1.3-SNAPSHOT/src/pom.xml
./foo-1.3-SNAPSHOT/foo-c-1.3-SNAPSHOT.jar
./foo-1.3-SNAPSHOT/foo-b-1.3-SNAPSHOT.jar
./foo-1.3-SNAPSHOT/foo-examples-1.3-SNAPSHOT.jar
./foo-1.3-SNAPSHOT/foo-a-1.3-SNAPSHOT.jar
(Yes, the full base directory happens twice for sources but once for binaries.)
Conversely, if I add
false to the assembly
descriptor and rebuild, I get
$ cd target/foo-1.3-SNAPSHOT.dir/
$ find
./src/src/main/java/foo/examples/Example.java
./src/src/main/java/foo/examples/package-info.java
./src/pom.xml
./foo-c-1.3-SNAPSHOT.jar
./foo-b-1.3-SNAPSHOT.jar
./foo-examples-1.3-SNAPSHOT.jar
./foo-a-1.3-SNAPSHOT.jar
Which is much closer to what I want, but is missing the base directory
(a bigger issue in the zip and tarball releases, which shouldn't stomp
on the current directory when unpacked).
Is my only option to set includeBaseDirectory=false and "hand-craft"
the base directory in with ${property}s?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
