karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Topping <topp...@codehaus.org>
Subject Re: 3.0.0 release branch testing
Date Mon, 30 Apr 2012 15:01:49 GMT
Thanks for the detailed response, Andreas.  

I guess what I need to think about is how difficult it's going to be to live with this issue
as opposed to the complexity of doing these patches.  From the experience on a Java-based
web framework I was once involved with, patches that are too large don't get looked at because
they are too complex, and patches that are too small are either too difficult for the submitter
to separate out, or have dependencies on other small patches.  In the last case, the rejection
or change of one patch invalidates the entire remainder of the chain of patches.  

(It's a little off-topic, but I'd be interested to hear how others have managed this situation
back when they were pre-committer....)

Right now, I already have a patch to a bunch of POMs outstanding, and for the reasons above,
I'm a little nervous about creating any new patches to the POMs until those are accepted.
 Those patches are to mirror the features that are generated with proper Maven dependencies
in the POMs of the features.  In doing so, karaf-maven-plugin can properly manage dependencies
in situations where the feature's metadata is insufficient to discern exactly which dependency
a feature relies on.  On my local machine, I have karaf-maven-plugin generating very clean
features.xml without bundles that are otherwise provided by feature elements that have already
been included.  Because I have explicit dependencies available, I'm also able to automatically
generate repository elements into the features.xml.  I'm sure there will be improvements to
it over time, but I'm running into a wall with how much more I can do until the existing patches
are accepted.

Cheers, Brian

On Apr 29, 2012, at 12:13 PM, Andreas Pieber wrote:

> I need to give this a shot within the next 1-2 weeks. If you can wait
> that long I can give you an entire description how to do your own
> local releases. If you need it faster feel free to play around and
> provide the patches to the code and the documentation youself;
> nevertheless, since fuse & talend do their own releases I'm not sure
> if it's really a problem with the versions.
> Basically, to do own releases, you need to replace the apache ueber
> parent with your own (which is basically a copy of the apache ueber
> pom where the distributionManagement/repository sections are
> corrected). The same parts will need to be adapted locally for karaf.
> This should do the trick; what other problems do you encounter? What
> exactly are the errors?
> Kind regards,
> Andreas
> On Sat, Apr 28, 2012 at 07:42, Brian Topping <topping@codehaus.org> wrote:
>> Hi all,
>> I've created some patches in https://issues.apache.org/jira/browse/KARAF-1390 that
I'd like to have in my workflow.  Every morning, I end up with new downloads from Hudson because
the snapshots have changed.  Makes good sense, so I wanted to create a locally released plugin
that I could use until the patches get applied in one form or another.
>> First, I tried to version the plugin POM and do a build, but I believe that didn't
work because of a large number of ${project.version} property substitutions throughout the
POMs, causing the dependency POMs to not have a version of a dependency with my newly created
${project.version} and filed https://issues.apache.org/jira/browse/KARAF-1421 toward it.
>> But I am realizing that may not be the case, as I tried to substitute all the version
numbers on all the POMs and do a build and it still fails.  (I realize it's a large dependency
chain that would be built, but I don't have time to waste on this.)
>> Does anyone have ideas they could share on how to work around this?
>> Thanks, Brian

View raw message