Hi Joel,
I found that feature, but a developer on the mailing list said that it
won't be enabled until 2.1. I've put the XML in the POMs (commented out)
and am waiting for that release so we can start using it.
Maven has a way to include resource files and metadata (META-INF) files in
the build of each JAR (POM). I do this for the .properties files. I think
it is possible for us to put the proper manifest file (with OSGi goodness)
into the repository and then have Maven pick it up and include it in the
JAR. So far the examples I've seen relate to user-defined
(non-Manifest.mf) files, but it's worth a shot. Then all of the JAR files
would be OSGi bundles.
If you'd like to take all of the JARs in Muse and make one OSGi bundle out
of them, it would probably be best to run the build as-is, then create a
script that copies {local-repository}/muse/*/2.0.0-M1-SNAPSHOT/*.jar into
one directory and JARs them up. I'm not sure if this was your ultimate
goal or if the previous paragraph covers that.
Dan
Dan Jemiolo
IBM Corporation
Research Triangle Park, NC
+++ I'm an engineer. I make slides that people can't read. Sometimes I eat
donuts. +++
"Hawkins, Joel" <[EMAIL PROTECTED]> wrote on 06/27/2006 04:14:24
PM:
> Dan,
>
> Thanks - good to be back (well, sort of!).
>
> http://maven.apache.org/guides/mini/guide-archive-configuration.html has
> some info on suppressing maven's metadata in archive files, in case you
> haven't found it yet.
>
> I'm trying to figure out how to get maven to do something as simple as
> unjar an archive so that I can update it's manifest (repackaging for
> OSGi). I feel like I'm wandering in the woods looking for breadcrumbs!
> I'm afraid to even think about how to do automated testing under Maven.
> Andrew, I'm all ears at this point. Ah well, back to searching.
>
> Cheers,
> Joel
>
>
> -----Original Message-----
> From: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 27, 2006 3:15 PM
> To: [email protected]
> Subject: RE: status of the build
>
> Joel! Welcome back to the program!
>
> I wonder if this is a JDK issue - I thoug that the basic XPath APIs were
>
> part of the core JDK and that Xalan was not required, but I suppose
> that,
> like JAXP/DOM, there may be some discrepancies. Or I may just be wrong.
> My
> dev JDK doesn't have Xalan in /lib/endorsed, but I have five JDKs on my
> system, so I will look into that some more. In the meantime, I will
> update
> the build with your fix.
>
> The test cases (unit and other) bring up an important topic. In the
> past,
> I have kept all tests/test projects as separate projects or modules.
> They
> had a copy of the latest jars from the build, but there were no
> dependencies between the test projects and the source tree. I did this
> to
> make sure that new people could come in and run the tests (and tweak the
>
> tests) without setting up the full build.
>
> I would like to consider this as we decide how to set up and record the
> tests in /trunk. Our current test/sample projects are stored in a way
> that
> is easy to ship but may not be optimal for daily tests. I'm open to
> suggestions. Andrew, I know you've thought a lot about the test harness
> in
> general - would you like to make a proposal before I make my own? Joel,
> you may have (will have) OSGi-specific things that need to be considered
>
> when setting up the test harness, so be sure to educate us if we're
> oversimplifying for the Axis2/POJO scenario.
>
> Dan
>
>
>
>
> "Hawkins, Joel" <[EMAIL PROTECTED]> wrote on 06/27/2006
> 02:40:45
> PM:
>
> > Dan,
> >
> > I hit a snag when trying to build xml-utils. I found that the
> following
> > dependency was needed in the pom in order to build the XPath utility
> > classes.
> >
> > <dependency>
> > <groupId>xalan</groupId>
> > <artifactId>xalan</artifactId>
> > <version>2.7.0</version>
> > <scope>compile</scope>
> > </dependency>
> >
> > Once I tossed that in, everything went smooth. Am I missing something,
> > or do you have more mojo in your environment than I do? :-)
> >
> > Starting to work on the OSGi build stuff now. Any ideas on how you'd
> > like to handle unit test cases, etc.?
> >
> > Thanks,
> > Joel
> >
> >
> >
> > -----Original Message-----
> > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 15, 2006 5:43 PM
> > To: [email protected]
> > Subject: status of the build
> >
> > I have created a Maven-based build for each of the source code modules
> > in
> > /trunk/modules. There is a build-all.bat file that ties these together
>
> > because it does not appear that Maven 2.0 allows users to tie together
>
> > multiple project files into one aggregate project. If I'm wrong about
> > this, I'd be happy to make the change necessary to create a "pure"
> Maven
> >
> > build.
> >
> > Because of Maven's "one jar file per project" rule, I have split some
> of
> >
> > the WS-* modules into two projects - one for API, one for
> > implementation.
> > This required a change to the projects' directory structure, so the
> code
> >
> > for those projects will have to be re-commited (under the new
> > directories). I apologize ahead of time for the extra noise on
> > muse-commits. I originally thought that Maven would allow me to
> generate
> >
> > multiple jars from a single source tree, but answers to past queries
> on
> > [email protected] indicate that "one jar file per project" is the
>
> > only way to go.
> >
> > My next steps are:
> >
> > 1) add the .properties files containing error/log messages to the
> build
> > jars
> >
> > 2) figure out how to get Maven to stop including its metadata files in
> > the
> > build jars
> >
> > 2a) if #2 is not possible, update the build-all.bat file to strip them
> > out
> > manually
> >
> > 3) add the test projects to the build - I'll do this in a way that is
> > similar to other ws.apache.org projects
> >
> >
> > Dan
> >
> >
> >
> > Dan Jemiolo
> > IBM Corporation
> > Research Triangle Park, NC
> >
> >
> > +++ I'm an engineer. I make slides that people can't read. Sometimes I
> > eat
> > donuts. +++
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > The contents of this e-mail are intended for the named addressee only.
>
> It
> > contains information that may be confidential. Unless you are the
> named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> > ---------------------------------------------------------------------
> > 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]
>
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
> ---------------------------------------------------------------------
> 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]
