Re: initial commit

[Craig L Russell]

Maven is pretty good at building, testing, and packaging for release without a lot of manual intervention. I think we would need to create a separate maven goal to repackage the jars into the final jar distribution but maven allows you do create pre- and post-goals to do just what you need to do.

Craig

On May 30, 2006, at 7:47 PM, Eddie O'Neil wrote:

The alternative is to get a change into maven that would somehow recognize multiple source directories (by filtering, e.g. **/jdk14/**/ *.java and **/jdk15/**/*.java) and build them into one target jar file. But this seems pretty tricky, and building the javadoc might be even trickier... I guess if it were up to me, I'd probably start by getting maven to build a separate jar for the 1.4- and 1.5-dependent source trees, which we think works. And then getting standard maven to package them into the distribution that we want. Once we know the differences in the 1.4 and 1.5 maven files we can see if a reorganization is needed.

 For sure -- that would be simples, but I have to imagine (and could
be dreaming) that we can bend Maven to our will and have separate,
individually configured / built modules that can be rolled into a
single JAR file at the end.

 That keeps the number of JARs from exploding (Maven's natural
tendency) while still enforcing a specific language version at compile
time.



Eddie






On 5/30/06, Craig L Russell <[EMAIL PROTECTED]> wrote:

Craig, in your Maven experience, do you think such an approach is possible?

On May 30, 2006, at 5:27 PM, Patrick Linskey wrote:

>> Would it be ok to build three different jar files based on
>> whether the target was 1.3, 1.4, or 1.5? Packaging the
>> different jar files into one could be a post-build exercise.
>> Or a specific build target that combined the three jar files.
>>
>> How is the source code structured today?
>
> That could work I guess. For the most part, a given module is in
> only one

> Probably we only will need special 1.4 and 1.5 code areas for one
> module in
> particular.

For sure, you need the implementation of second class objects for the
1.4-specific classes and interfaces. And for 1.5, it's the entire
annotation processor. If these can be separate maven projects that
build their own jars that would be the simplest approach.

Craig

>
> -Patrick

> _
> Notice:  This email message, together with any attachments, may
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.

Craig Russell

> language version, but there are a fewt scattered exceptions to this. > _____________________________________________________________________ _ Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature