I'm a bit confused by the initial problem posed in this thread. This may
expose a fundamental misunderstanding of Java on my part, but if so I'd like
it cleared up by this fine group sooner rather than later.
I routinely build a project for a CDC target using a Sun J2SE 1.3 boot class
path, and run the same class files on Sun J2SE VMs (1.3, 1.4 and 1.5) and
IBM's J9 CDC VM (1.3). Using the CDC classpath would probably be better
since that's the more restrictive environment, but the point is that Java
class files are portable. As long as you build to byte code compatible with
the oldest VM and comply with the API of the most restrictive environment,
the class files should run on any VM regardless of what your classpath looks
like when you compile, right? This has always been my understanding, and has
also been my experience. Optimizing doesn't appear to affect this, either.
So, if the source code is truly unchanged, why not always compile with the
oldest and/or most restrictive JDK libraries, and run it wherever you want?
Have the optimizing compilers gotten so much better that it's worth the
extra hassle of maintaining two sets of distribution jars? Do newer VMs run
notably slower with older byte code, again enough to be worth the
maintenance hassle?
Are you using an ahead-of-time compiler to go all the way to executables?
Even then, I'd think the build solution would be to javac to a jar you could
use anywhere then AOT the jar to your embedded target. Is there JNI, in
which case you have all the usual non-Java problems with target platform
portability?
What am I missing?
Jay
>Yes, this is supported through profiles in alpha-3. You can try it from SVN
today, or wait for the release next week. Some of the repository support may
still need some work, so we'd be interested to hear your experiences.
>
>Cheers,
>Brett
>
>On 6/17/05, Shane Isbell <[EMAIL PROTECTED]> wrote:
>> By separate executions, I mean separate executions of xml.pom[myproject].
>>
>> On 6/16/05, Shane Isbell <[EMAIL PROTECTED]> wrote:
>> > Say the project structure is something like
>> >
>> > <myproject>
>> > ---pom.xml
>> > +--<subproject 1>
>> > ---pom.xml
>> > +--<subproject 2>
>> > ---pom.xml
>> >
>> > In this case, the pom.xml[myproject] is the parent project. What I
>> > am trying to find out is if there is way to type
>> >
>> > m2 {target -CDC} install
>> >
>> > and have this target request proprogated to pom.xml[subproject 1]
>> > and pom.xml[subproject 2]. Separate executions of m2 {target -CDC}
>> > install and m2 {target -J2SE} install are ok as long as the
>> > repository handles separate versions of the JAR.
>> >
>> > Can this be done through the profile?
>> >
>> > Thanks,
>> > Shane
>> >
>> > On 6/16/05, Brett Porter <[EMAIL PROTECTED]> wrote:
>> > > This sounds more like a profile solution, where the developer
>> > > picks which one they want to use.
>> > >
>> > > m2 --profile=CDC package
>> > > m2 --profile=j2se package
>> > >
>> > > You said earlier you wanted to have a parent project that would
>> > > build both, though. Can you elaborate on that? This is the part
>> > > that is not currently supported, the profile executions must be
separate.
>> > >
>> > > Thanks,
>> > > Brett
>> > >
>> > > On 6/17/05, Shane Isbell <[EMAIL PROTECTED]> wrote:
>> > > > Hi Brett,
>> > > >
>> > > > The use case is as follows: Each sub project has a single set of
>> > > > source files. The developer sets a target flag to CDC or J2SE.
>> > > > Depending on the flag, the build tool compiles the Java source
>> > > > files under either CDC or J2SE. In the case of CDC, the build
>> > > > tool uses a different bootclasspath during compilation. Next.
>> > > > the build tool packages the classes within a jar file, appending
>> > > > <myfile>-<platform>.jar, where platform is either CDC or J2SE,
>> > > > depending on the target. End.
>> > > >
>> > > > The reason that I do not want to split these into separate
>> > > > projects is that the source files are the same. If a developer
>> > > > modifies, say the CDC source, it is not reflected in the J2SE
>> > > > source, which leads to versioning problems. Given that I am
>> > > > compiling with different bootclasspaths, I do not believe that
>> > > > the solution that you outlined below would work. I will however,
look into it.
>> > > >
>> > > > Regards,
>> > > > Shane
>> > > >
>> > > > On 6/16/05, Brett Porter <[EMAIL PROTECTED]> wrote:
>> > > > > In Maven, a POM is a unit of work, so a project must have just
one.
>> > > > > Usually, targetting multiple platforms involves setting up
>> > > > > multiple projects.
>> > > > >
>> > > > > pom.xml - parent that has <modules/> for the following:
>> > > > > +- foo-common/pom.xml - shared information
>> > > > > +- foo-j2se/pom.xml - j2se specific build, depends on
>> > > > > +foo-common
>> > > > > +- foo-cdc/pom.xml - CDC specific build, depends on foo-common
>> > > > >
>> > > > > Does this suit your situation? What are the actual differences
>> > > > > between the two platforms?
>> > > > >
>> > > > > We currently have a new solution for environmental specifics
>> > > > > in
>> > > > > alpha-3 (profiles), however these are not intended to be used
>> > > > > to build multiple artifacts from a single build, but rather
>> > > > > building differently in separate environments. You may have
>> > > > > justification for allowing them to be incorporated into a
>> > > > > single build, so I'd like to walk through the use case with you.
>> > > > >
>> > > > > Cheers,
>> > > > > Brett
>> > > > >
>> > > > > On 6/17/05, Shane Isbell <[EMAIL PROTECTED]> wrote:
>> > > > > > For my current project, I am testing a migration from ANT to
>> > > > > > Maven 2.0 (alpha 2). I have encountered an issue that I am
>> > > > > > unable to resolve. I have a single source tree, but I need
>> > > > > > to compile and package a JAR for two different platforms:
>> > > > > > J2SE and CDC. I have built two separate pom.xml files:
>> > > > > > pom-J2SE.xml and pom-CDC.xml, within the same directory. I
>> > > > > > was hoping there would be a command similar to ant: ant
>> > > > > > -buildfile <myfile> but I have been unable to find it. If
>> > > > > > this is a possible solution, I also need to manage the
>> > > > > > entire platform build from a master pom.xml, which propagates
target platform information down to the sub projects. Is there a feasible
solution in Maven 2.0?
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Shane
>> > > > > >
>> > > > > > ------------------------------------------------------------
>> > > > > > --------- To unsubscribe, e-mail:
>> > > > > > [EMAIL PROTECTED]
>> > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > > > >
