[MAGNOLIA-3545] Enable usage of Maven's scope:import for our webapps and bundles Created: 09/Feb/11  Updated: 21/Oct/13  Resolved: 29/Jul/13

Status: Closed
Project: Magnolia
Component/s: build
Affects Version/s: None
Fix Version/s: 5.0.2, 5.1

Type: Improvement Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File MAGNOLIA-3545-trunk.patch    
Issue Links:
Cloners
is cloned by MAGNOLIA-5207 Enable usage of Maven's scope:import ... Closed
Relates
relates to MGNLUI-1877 Enable usage of Maven's scope:import ... Closed
causality
is causing ARCH-24 Update webapp/project archetypes to u... Closed
dependency
is depended upon by MAGNOLIA-3534 Update commons-digester dependency Closed
relation
is related to MGNLEE-284 Use scope:import if possible Closed
is related to MAGNOLIA-4728 Add demo-project / demo-features to c... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:

 Description   

To facilitate project builds, our webapps (magnolia-empty-webapp, magnolia-bundled-webapp, magnolia-enterprise-webapp) should have their dependencies (Magnolia jars) in a dependencyManagement section. Instead of "just" depending on the magnolia-empty-webapp's pom, they should do so with the import scope.

As a consequence, a webapp project would be able to do the following:

    <dependency>
      <groupId>info.magnolia</groupId>
      <artifactId>magnolia-bundled-webapp</artifactId>
      <version>4.3.8</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>

    <dependency>
      <groupId>info.magnolia</groupId>
      <artifactId>magnolia-module-dms</artifactId>
    </dependency>

This essentially "injects" the dependencyManagement section of magnolia-bundled-webapp:4.3.8 into the current project, so the project can now depend on magnolia-module-dms (for example) without specifying its version. This frees project developer from having to dig out exactly which version of each and every module they need was bundled with the Magnolia bundle they want to use. (which is a pita) And of course, they can still specify a specific version it they need to.

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope



 Comments   
Comment by Stefan Baur [ 03/Mar/11 ]

Good Morning

What is the status here? Will this change be implemented just before the release of 4.4.3?

Comment by Magnolia International [ 04/Mar/11 ]

Hi Stefan,

Yes this will go into 4.4.3 - currently no ETA on 4.4.3, though.

Comment by Stefan Baur [ 04/Mar/11 ]

will you not implement it a while before release?

Comment by Magnolia International [ 28/Jul/11 ]

Here's a patch for the current trunk.
When applying, carefully inspect all builds (webapps, bundles, ce and ee) to make sure all included dependencies are still correct.

Comment by Jan Haderka [ 06/Mar/12 ]

Why was this change rolled back? Can you describe what was wrong with it in more details then just "well it looks like there is more to fix ..."
Also when patch was applied, the commit comment didn't include issue number which makes it harder to track now.

Comment by Magnolia International [ 06/Mar/12 ]

The issue number (this one) was included, which is why Hudson commented it

I was originally hoping that using scope:import in the archetypes would benefit users of the archetypes, even before this issue was fixed. It made things worse, or more complex, so I commented that bit out, with the comment that Hudson left above.

In short, the status is that nothing was ever done in Magnolia itself about this issue.

The patch can not be applied as-is for several reasons

  • it's outdated by now, and it's meant as an example, really. At the time I posted it, it was applicable as is, but
  • ideally, the same principle should be applied to other projects, for example the bundles and their webapps.
  • there might be side effects, rippling in other bundles. Someone will need to carefully check bundle contents, etc.

Ideally, whoever starts to work on this should have a good grasp of what it does I'll be happy to fill people in if needed, but I'd think the description of the issue explains how this would be useful, as well as Maven's docs for a more general background.

Comment by Jan Haderka [ 14/Mar/12 ]

Make changes as soon as trunk is 5.0 so we can check for side effects when releasing Betas and RCs.

Comment by Magnolia International [ 23/Apr/13 ]

In fact, we should not only do this for webapps, but also (at least some) modules such as magnolia-core.

Comment by Magnolia International [ 11/Jul/13 ]

Finally making some progress on this, first with EE though: MGNLEE-284.

Comment by Magnolia International [ 24/Jul/13 ]

Tentatively scheduling this for 5.0.2. If there is more to do, will split issues.

Comment by Magnolia International [ 29/Jul/13 ]

Done for CE and EE bundles/webapps. Split further improvements into MAGNOLIA-5207 and MGNLUI-1877

Comment by Magnolia International [ 05/Aug/13 ]

Similar changes can be applied to fix MGNLUI-1877

Comment by Stefan Baur [ 08/Aug/13 ]

Good work takes time...

Thank you!

Comment by Stefan Baur [ 27/Aug/13 ]

One question here:

Is this only applied to the 5.x poms, or are the fix versions for 4.5.x just missing?

Comment by Magnolia International [ 03/Oct/13 ]

sbaur sorry for not seeing your question earlier, but yes, only applied to 5.x

Comment by Stefan Baur [ 21/Oct/13 ]

ok thx!

Generated at Mon Feb 12 03:47:29 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.