Hi, On Wed, Nov 16, 2011 at 12:00 PM, Carsten Ziegeler <[email protected]> wrote: > Hmm, first time users have to read the docs anyway
We're talking about Maven users here, who already understand the POM format and how to manage normal dependencies, so you only need to learn extra stuff if you're dealing with a separate bundle list file. I'm talking about people who only need to do simple stuff like update the version of a bundle or add a new bundle to the list. Such stuff should be as simple and straightforward as possible. > The answer is easy: these things don't work and are by > intention this way. So if I do need features like these, I shouldn't be using the launchpad plugin? > The number one rule is: no surprises and therefore you have to > configure the full dependency list including versions. We explicitly > came up with the partial bundle list. If you want to assemble an > application you really want to specify what you want to have in there, > so transitive deps etc. should not be used at all here. A proper Maven dependency tree already contains all the information you need to assemble working set of bundles. Why should I need to throw that information away just to duplicate it in the bundle list file? If you're worried about bloating the POM file, I'd say not supporting transitive dependencies is a way bigger cause of bloat in the bundle list file. For example, I'm trying to manage the dependency list of a large component (CRX server bundle) that requires about a dozen upstream bundles as dependencies. Instead of having just a single dependency in the partial bundle list project for this and all required transitive dependencies, I have to duplicate the entire list of bundles and manually make sure that their versions are correctly updated when the dependencies change. > And just by having dependencies inside the plugin configuration. this > doesn't work either. Correct. IMHO we should be using normal project level dependencies for the bundles included in the bundle list. > Ah, ok, we asked the maven gurus last week and they told us the > opposite. I haven't validated it yet. If that's the case then I'm fine > if we use the exact same format as we use for the external file inside > the plugin configuration. Not sure if we're talking about the same thing here, but here's a screenshot of the introspection at work with a vanilla Eclipse Indigo installation: http://people.apache.org/~jukka/2011/m2e-introspection.png > I really like the external XML file - it's imho the best way to > specify an application assembly. I'm not opposed to the idea of an external XML file as such, for example it works pretty well for the assembly plugin. But just like is done in the assembly plugin, I'd very much like to see the actual dependencies managed as normal Maven dependencies and only referenced in whatever configuration (plugin configuration in the POM or an external configuration file) is used to construct the resulting assembly. If we can keep the dependencies as normal <dependency> entries in the POM (with standard handling of transitive dependencies, dependencyManagement, etc.), I'm basically fine with whatever mechanism is used to configure the rest of the build. BR, Jukka Zitting
