openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: initial commit
Date Wed, 31 May 2006 03:39:08 GMT
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.

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.

Craig

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

>  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.
>
>  Craig, in your Maven experience, do you think such an approach is  
> possible?
>
> Eddie
>
>
>
>
>
>
> On 5/30/06, Craig L Russell <Craig.Russell@sun.com> wrote:
>>
>> 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
>> > language version, but there are a fewt scattered exceptions to  
>> this.
>> > 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
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>

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


Mime
View raw message