Re: Installing effective Maven POM files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
> From: "Mikolaj Izdebski" <mizdebsk@xxxxxxxxxx>
> To: "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx>
> Cc: "java-devel" <java-devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Friday, February 22, 2013 11:43:34 AM
> Subject: Re: Installing effective Maven POM files
> 
> > OK, the simplest case that would not work for us if we can't make
> > use
> > of the normal poms.
> > 1. eclipse-cbi-plugin calls eclipse to run various tasks
> > implemented
> > in eclipse
> > 2. the bundle set needed to run eclipse is defined in
> > eclipse-parent
> > 3. eclipse platform changes and adds additional bundle
> > 4. eclipse-parent is updated to add new dependency
> > 5. eclipse-cbi-plugin can't be rebuild as it requires to run
> > eclipse
> > which needs additional bundle which is in the parent but not in
> > eclipse-cbi-plugin package. I know that cyclic dependencies are bad
> > but these is the norm in Java land and this is not the only cycle.
> > 6. if in this case we can call mvn-rpmbuild which relies on normal
> > poms - no problems as parent is correct.
> 
> I already provided a solution for this case - read my previous
> emails.
> 
> Do you have any *other* problems with effective POMs?
> 
> > Note that patching eclipse-parent pom to add xmvn configuration is
> > not ideal solution as it would mean that xmvn would need to be
> > resolvable in case one runs pure mvn or during development one
> > would
> > need to switch between upstream/fedora eclipse-parent pom (e.g. one
> > runs mvn-local and gets a failure, run pure mvn to test whether
> > it's
> > smth in fedora that caused the problem and things fail because xmvn
> > is not resolved).
> 
> That is not true. XMvn configuration is placed in pluginMagement.
> Plugins described in pluginMagement don't need to be resolvable.
> Exactly the same solution is used in other projects, even on eclipse
> side (Eclipse M2E stores its configuration exactly in the same way
> (in pluginManagement in POM).
> 
> > As much as this might sound imaginery to some
> > people this is common case if you both work upstream and keep care
> > of the integration in Fedora. Any such modification introduces
> > churns which are very easy to overlook and either push to upstream
> > xmvn specifics or push to Fedora without xmvn configs so break
> > other
> > things later.
> 
> Maintaining your own configuration is fairly simple. With POM macros
> you don't even need to patch your POM files - configuration can be
> specified directly in the spec file and injected during the build.
> As long as you don't want to modify the semantics the maintenance
> cost of this solution is close to zero.
> 
> Pushing XMvn configuration to upstream is an option - it won't affect
> upstream build at all. Many upstreams include M2E configuration in
> their POMs, which is analogous to XMvn configuration.
> 
> > Keep mvn-local/mvn-rpmbuild to use normal poms and I would have no
> > objections.
> 
> That's not an option. This would cause severe problems with
> dependencies. Let me give an example.
> 
> apache-commons-io installs effective POM and normal POM. It doesn't
> Require apache-commons-parent. If you use mvn-rpmbuild to build the
> package you either need to either BuildRequire apache-commons-parent
> in your package or the build will fail because of missing parent POM.

One more question - if I configure my parent pom to never be embedded I would still have to care for adding BRs myself, right? So no additional problems would arise from being able to use mvn-rpmbuild/local that rely on normal poms.

Alexander Kurtakov
Red Hat Eclipse team

> 
> --
> Mikolaj Izdebski
> 
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel



[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux