3.0.0 release branch testing

[Brian Topping <to...@codehaus.org>]

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

Re: 3.0.0 release branch testing

[Brian Topping <to...@codehaus.org>]

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 <to...@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

Re: 3.0.0 release branch testing

[Andreas Pieber <an...@gmail.com>]

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 <to...@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