Jerome Dochez wrote:
>
> On Nov 13, 2007, at 1:01 PM, Bill Shannon wrote:
>
>> I'm converting the GlassFish "mail" module to the maven2 directory
>> layout, as specified at
>> http://wiki.glassfish.java.net/Wiki.jsp?page=V3WorkspaceStructure
>> Rather than start with the CVS version of the module, I'm starting
>> with the "real" master workspace, which I've migrated from Teamware
>> to Mercurial. Ultimately I hope to publish it as a completely
>> separate java.net project/module.
>
> umh I already did some of that work at
>
> https://glassfish-svn.dev.java.net/source/browse/glassfish-svn/trunk/v3/api/mail/
>
>
> you should start from there probably...
Um, as owner of the mail module, it would've been nice if I had been
notified that you planned to do such work...
> to checkout follow the engineering guide.
It's on my list of things to figure out. I haven't gotten there yet.
>> In addition to build the JavaMail mail.jar file, I also want to be
>> able to build the JavaMail release zip file, which includes the mail.jar
>> file, other jar files, documentation, javadocs, demo source code, etc.
> in maven, these are several different jar files, you have the source.zip
> the javadoc.zip and the binary.zip
>
> are you particularly attached to your bundle format ?
Yes. I want the transition to the new build system to be transparent
to users of the JavaMail binary download bundle.
>> I haven't learned much about maven2 yet so I have some simple questions
>> about the directory layout...
>>
>> 1. Where should I put the documentation? Is a top level "doc"
>> directory ok?
>>
> where would it go in the packaged zip ?
I put it in a top level "doc" directory.
>> 2. Can I leave package.html and overview.html in the src/main/java
>> directory tree?
>>
> yes
>
>> 3. Where do I put sample/demo source code? When I make a JavaMail
>> release, I want to include the demo source code in the zip file.
>> And I want to be able to build the demos to make sure they build
>> properly before release, but the resulting class files aren't
>> included in the release. Most demos are simple, standalone,
>> independent applications. Should I put them all in src/demo/java?
>> Do I need a different directory under src for each one?
>>
> I put those files in the demo top level directory for now, I was
> planning to revisit that later. I think in theory you should create sub
> modules and so on but that seem very tedious to me.
Extremely.
>> From the same set of sources I build multiple jar files with
>> different combinations of sources. Each jar file needs its
>> own manifest and its own resource files. The manifest files
>> need to be preprocessed to (e.g.) fill in the correct version
>> number before use.
>>
> that would definitly force you into different sub-modules each with its
> resources/pom.xml
>
> something like :
>
> mail/pom.xml (mail-api pom.xml)
> mail/src/main/java (mail-api sources)
> mail/demo/pom.xml (list of demo modules)
> mail/demo/demo1/pom.xml
> mail/demo/demo1/src/main/java/...
> mail/demo/demo1/src/main/resources/...
> mail/demo/demo2/pom.xml
> mail/demo/demo2/src/main/java/...
> mail/demo/demo2/src/main/resources/...
> ...
This isn't about the demos (although that's a problem too).
I create imap.jar, smtp.jar, mail-api.jar, etc., and the content of
(almost) all of those are included in mail.jar.
I would really prefer to have one source tree, from which I can create
multiple jar files. Is there really no way to do that with maven?
If not, how do I create the mail.jar file based on the content of other
jar files?
If I have to have sub-modules, how do I name them? src/imap/java?
imap/src/main/java?
>> 4. Should I put all these manifest and resource files under
>> src/main/resources?
> no you have to split them like described above.
Yuck.
>> 5. Is there a way to preprocess these files before use, including
>> changing their names? Or do the things in src/main/resources
>> just get copied with no processing?
> you can process files while copying them, look for example how to
> process manifest files at
>
> http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
>
>
> With pom.xml I have in v3/pom.xml, all the api jar modules automatically
> contains the license file and the customized manifest, therefore your
> examples should probably not inherit the org.glassfish.api:api pom.xml.
> In fact they probably don't need a parent pom
Right now I'm just trying to get the build to work using ant. I'll
get back to figuring out maven some other day, at which point I'll
figure out what the above means. :-)