Re: Manifest customization: Where to find the docs?

[Greg Thompson]

Wayne Fay wrote:

OK let's get a little more explicit...

What are you currently getting out of Maven?
What do you want to get out of Maven?
What have you tried which did not work as you required?


This, like many responses I've seen on this mailing list, is venturing 
into "smarmy" territory.  Legitimate questions have been asked about a 
Maven component that is quite under-documented.



The final "work-around" is simply to write your own static Manifest
file and tell Maven where it is, and it will use it instead of
generating one itself. But this is a last-resort kind of thing,
usually.


It's also usually helpful to point people toward resources that might 
help them decide whether or not they need to take this last-resort 
(oops, a smarmy response from me).  I suggest that anyone interested in 
learning how to tweak their JAR manifests take a look at the source for 
MavenArchiveConfiguration and ManifestConfiguration in:


http://svn.apache.org/viewvc/maven/shared/tags/maven-archiver-2.2/src/main/java/org/apache/maven/archiver/

Here's a very simple example:


  

false


  true
  has a value
  has another value
  you get the idea
  
  
  

  
  
  true

--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using Maven with Eclipse well: mvn eclipse:eclipse and nested projects

[Greg Thompson]

Alan Kent wrote:
Q: Is there any way to make "mvn eclipse:elipse" generate a .project 
file for the root directory as well as each module?  That way I can 
check out the whole project tree from the root and have a project per 
pom file.


Not that I know of, but this works for me:

1. Check out the parent module into your workspace.

2. "mvn eclipse:eclipse" to create the various .project and .classpath
   files in the sub-modules.

3. Switch to the Java perspective in Eclipse.

4. Select the parent module and hit F5 to refresh (just for grins).

5. Choose "File->Import...", "Existing Projects into Workspace", and
   browse in your workspace into your parent module.

6. Select one of the sub-modules, make sure "Copy projects into
   workspace" is /not/ checked, and hit "Finish".

7. Lather, rinse, and repeat steps 5 and 6 with the other submodules.

In this way, you can do all of your SCM in Eclipse via the parent 
module, yet play with the submodules as proper Java projects.


As far as I know, this is the "recommended" way to develop a 
multi-module project with Eclipse.  Someone please correct me if I'm wrong.

--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CDATA in properties

[Greg Thompson]

Steven Rowe wrote:

Have you tried to add one or more levels to the entity expansion?

E.g., specify the following in your properties section:

 

Or equivalently:

 somestuff © 2007 somestuff.


Thanks for the reply, Steven.  The trouble with your suggestion is that 
I want the property's value to be precisely "somestuff © 2007 
somestuff." since the same property is being used in another context.

--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CDATA in properties

[Greg Thompson]

In my javadoc-plugin configuration, I currently have something along the 
lines of:




For various reasons, I'd like to move the value into a property.  So 
I've added this to my pom's properties:




and changed the javadoc-plugin configuration to:

${jdBottom}

while help:effective-pom says that the property has the proper value:

somestuff © 2007 somestuff.

the expansion of the property is being parsed as XML, yielding this in 
the javadoc-plugin configuration:


somestuff © 2007 somestuff.

This is most definitely NOT what I want.  Of course, the first thing I 
tried was to wrap the use of the property in the javadoc-plugin 
configuration in another CDATA:




This has no effect.

Is there any way to do what I want here?  Thanks.
--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Compile and jar two artifacts, one with a classifier, in one run?

[Greg Thompson]

I have a packaging=jar project for which I'd like to generate two jars: 
one non-debug (the default) and one debug (w/ classifier="debug").  Is 
this possible?  I've looked at trying to run the compiler:compile goal 
twice into different output directories, but that doesn't seem possible 
(outputDirectory is readonly and is set to 
${project.build.outputDirectory}).  Must I engage in some trickery 
whereby I bind two compiler:compile runs to the compile phase with a 
jar:jar and some ant junk to nuke the target/classes directory in between?


Thanks,
--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to set wagon-ssh-external's repository permissions?

[Greg Thompson]

In the source for ScpExternalWagon.java [1], I see that it has the 
capability to change the group and mode after putting files/directories, 
but I don't see how I set this stuff in my pom.xml or settings.xml. 
Where do I specify repository permissions group and filemode?  Is this 
documented somewhere?


Thanks.

[1]
http://svn.apache.org/viewvc/maven/wagon/tags/wagon-1.0-beta-2/wagon-providers/wagon-ssh-external/src/main/java/org/apache/maven/wagon/providers/ssh/external/ScpExternalWagon.java?revision=486344&view=markup
--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to set wagon-ssh-external's repository permissions?

[Greg Thompson]

In the source for ScpExternalWagon.java [1], I see that it has the 
capability to change the group and mode after putting files/directories, 
but I don't see how I set this stuff in my pom.xml or settings.xml. 
Where do I specify repository permissions group and filemode?  Is this 
documented somewhere?


Thanks.

[1] 
http://svn.apache.org/viewvc/maven/wagon/tags/wagon-1.0-beta-2/wagon-providers/wagon-ssh-external/src/main/java/org/apache/maven/wagon/providers/ssh/external/ScpExternalWagon.java?revision=486344&view=markup

--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Comprehensive list of packaging types?

[Greg Thompson]

Steven Rowe wrote:

There's a bigger list (though perhaps a bit dated) here:




Thanks, Steven.  None of the options on that list sound right for my 
needs (a non-Java project generating a bundle of documentation).  I'm 
not going to need to write my own plugin for something so simple, am I?

--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Comprehensive list of packaging types?

[Greg Thompson]

Is there a complete list of packaging types?  I see a short list on 
http://maven.apache.org/plugins/index.html, but I imagine that there are 
other plugins that provide other kinds of packaging.


Is there a simple way to grep through the plugins in a repository to see 
what packaging they provide?


I ask partly out of curiosity, and partly because I have an ant-based 
"project" that generates a set of documents .  If I were to mavenize 
this, I imagine that the bundle of documents would be installed/deployed 
so that it would be available to other projects (which may create 
assemblies containing the documents along with bits and pieces of other 
projects/modules).  So what would I set the packaging to for this 
document project?

--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven, CVS, Eclipse, and Continuum

[Greg Thompson]

Christian Bauer wrote:

Hi Greg,

you can avoid topic

2.a) ... This is sub-optimal, as each module is really in the 
workspace twice, once as a top-level Java project and once as a 
sub-directory in the parent project.


by only checking out the root project (with all sub modules) and then
importing the modules from the the location within the root project.You
then have multiple projects, but only one codebase in the workspace.
This is very easy with Eclipse 3.2.2, in Eclipse 3.2.1 you should not
check out the root project  into the workspace but into another
directory and import from there.


Thanks, Christian.  That's actually what I had done.  So you really have 
two "views" into each module: one through the parent (where the checkout 
really is), and one through the module's project (which is really a 
pointer into the parent).


Is this the recommended way (path of least resistance)?  Especially in 
comparison to a flat layout?

--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven, CVS, Eclipse, and Continuum

[Greg Thompson]

It seems that there are many rough edges relating to multimodule project 
development in Eclipse.  I've searched the mailing lists and found 
various people saying that they have usable setups, but I'm not sure 
that I buy it.  I've tried:


1. Flat project layout: parent POM references child modules as 
"../module1", while the children have relativePath to 
"../parent/pom.xml".  The CVS layout is the same: blahblah/parent, 
blahblah/module1, blahblah/module2.  Problems with this are, at least:


a. continuum checks the projects out into numbered directories, thereby 
breaking the relative references.


b. generating the site from within continuum yields broken links here 
and there.


c. continuum aside, I seem to recall that the site plugin does odd 
things in this configuration.


2. Nest project layout: parent POM references child modules as 
"module1", while the children use the default relativePath.  The CVS 
layout matches: blahblah/parent, blahblah/parent/module1, 
blahblah/parent/module2.  Problems with this are, at least:


a. to get the projects into Eclipse, we have to jump through hoops like 
check out the parent into the workspace (so we have a "parent" project), 
use the eclipse:eclipse goal to generate files, and then "import" the 
modules as eclipse projects (so we have a "module1" project and a 
"module2" project).  This is sub-optimal, as each module is really in 
the workspace twice, once as a top-level Java project and once as a 
sub-directory in the parent project.


b. when adding to Continuum, Continuum checks out the parent and each 
module as separate projects (even though all modules are sub-dirs of the 
parent).  I have to manually delete the modules so that there's only the 
parent in continuum, and then remove the --non-recursive option.


Surely someone has figured out a better way.  Is such better way clearly 
documented somewhere (rather than in a scattering of email messages that 
may or may not be relevant given recent changes to Maven, Continuum, and 
the myriad plugins involved)?


Any advice would be appreciated.  Thanks.
--
-Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]