Hi, Jerome.
This discussion brought to mind the issue I raised with you a while ago,
about components of the system in V3 that might need to produce both a
client-side and a server-side JAR file to help reduce the ACC footprint.
I remember at the time we talked about this requiring two separate
modules for such a component. What are the advantages and disadvantages
in your mind of submodules vs. entirely separate modules to cover such a
situation? Your response to Bill implies that submodules are painful,
or is that just in his case given what he wants to do?
It would be good to know this as we have more of the module
presentations, just so module owners who might need to do this could be
pointed in the right direction.
Thanks.
- Tim
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...
>
> to checkout follow the engineering guide.
>
>>
>>
>> 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 ?
>
>>
>>
>> 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 ?
>
>> 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.
>
>> 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/...
> ...
>
>> 4. Should I put all these manifest and resource files under
>> src/main/resources?
> no you have to split them like described above.
>>
>>
>> 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
>
> jerome
>
>>
>>
>> I'm sure I'll have more questions once I start figuring out how
>> to actually use maven2 to build my module...
>>
>> Thanks!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>