Next milestone of Bundlor?

[dsklyut]

Hi,

Bundlor has been sitting on M6 for a while now.
When can we expect a new revision?

The major issue we are facing is web apps, where spring context files not in the default location (i.e. META-INF/spring) never scanned.

Placing files in META-INF/spring triggers double application context creation, one by dm-extender and second by DispatcherServlet. (we are working with dm-server 2.0)

I played with SNAPSHOT and that seems to address the part of scanning all xml files.

There are still number of issues with Maven plugin:

1. POM projects are not skipped
2. Generated MANIFEST.MF is not picked up by maven archiver. Need to do extra config to tell maven that we really, really, really want to use our generated MANIFEST.MF. Maven does not care that MANIFEST.MF is present in classes/META-INF, it just creates its own. This is more of a maven issue than bundlor, but listing anyway.
3. Not all of them maven poms are out there to be pulled down. I know we are dealing with SNAPSHOT, but still . Example:

com/springsource/util/com.springsource.util.common/2.0.0.CI-211/com.springsource.util.common-2.0.0.CI-211.pom
and
com/springsource/util/com.springsource.util.math/2.0.0.CI-211/com.springsource.util.math-2.0.0.CI-211.pom

[Ben Hale]

Dimitry,

A quick update on where Bundlor is these days. A couple of weeks ago I got a nice three-day block in which I did a massive amount of work on Bundlor and really got it to where it could be a releasable product. The snapshots that you're using are maybe 2-3 hours away from a milestone release (need to remove some external dependencies and get the documentation up to scratch) and my plan is that it'll actually be a 1.0.0 release candidate!

To address the issues you've listed.

1. I know that POM projects aren't skipped and I'm trying to come up with a good way of identifying the list of project types that should be skipped. There's is a flag to disable bundlor which can work in the mean-time, but this is one of the big things that I know I need to solve before RC.

2. I realize that the generated manifest is not automatically picked up by the Maven Archiver. This is actually exactly equivalent to the behavior on the ANT side, so I'm not sure that it's going to change for the 1.0.0 release. The mitigating factor that isn't pushing me to change it is that I can't find a clear and concise way to configure the archiver plugin programmatically from inside another mojo.

3. I'll take a look into the missing POM issue, but that's surprising to me as I can get the samples to build properly.

Keep an eye out for an RC1 sooner rather than later.

[dsklyut]

Ben,

Thank you for response.

I just noticed another issue. Bundlor fails with error if project does not contain target/classes folder. Sometimes I just want to build a bundle with static resource that are not in classes.

Bundlor also fails if outputPath does not exist.

For example I would like to place all generated code/files under target. So I specify outputPath=${basedir}/target/generated-resources/ but generated-resources is not created.

Looking forward for next release!