Hi Jay,
Your understanding is perfect. My use case is not well-defined. In
certain sub projects, the source code (with the same interface but not
implementing code) is split between CDC, which requires some private
native methods and J2SE, which does not. I have resolved this by
splitting the packages into package-A-CDC, package-A-J2SE and
package-A-Interface.
In other sub projects, the code is the same, but the dependent Java
packages are different (the original J2SE lib and a CDC port,
potentially with additional native methods-JNI), so my problem
revolves around testing under CDC and J2SE. This is where I need to
clarify things. The CDC port may not be complete, it may be broken or
may be non-existent, depending on the phase of the project and on
whether we have recently changed the targeted platform. The J2SE test
is the constant in these cases and needs to be supported. At a general
level, this is a problem of testing a single package under two
different dependent package versions.
I suppose I could solve this by having package-B,
package-B-platform1-CDC-test and package-B-J2SE-test. Of course, I am
still left with duplicated test code. Being new to Maven, I am not
sure the best way to handle this. Any ideas would be much appreciated.
Thanks,
Shane
On 6/17/05, Jay H. Hartley <[EMAIL PROTECTED]> wrote:
> 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]
>
> >> > > > > >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
