Hi Pavel,
On 2013-04-09, at 5:09 AM, pslegr wrote:
> >> I'm not sure I'm keen on this "separation of demo topics" approach. We're
> >> not planning to keep a ton of demos in the project (we decided that
> >> together in last week's hangout). So I think it would be best to throw all
> >> the demo projects under a single directory.
> Ok, this would certainly look better, but every examples "separated by
> topics" do have quite different requirements wrt its pom's
> In case all the examples will be in the same folder, then how do you want to
> aggregate the things examples have in common
We don't want the demo poms to have parent poms. There are three reasons for
this:
1. This means the demos can be copied and modified by someone who is starting
their own project
2. The poms should be easier to understand, since they are not inheriting any
properties or plugin configuration
3. The JDF quickstarts collection does not allow parent references, and we're
hoping to contribute some demos to that collection. If our own demos follow
their rules, it will be easier to keep everything straight
> >> One other thing that I think is different from what we had planned to do:
> >> in 3.0_p, the bus demos still depend on a parent POM. JDF required demos
> >> to have top-level poms (no reference to a parent), and we were planning to
> >> follow that. We can & should still have an errai-demos pom which refers to
> >> all the demos as submodules, so the demos are built when we build
> >> errai-parent. But we don't want the demo poms pointing back up to that
> >> parent.
> in the .../errai-demos/errai-bus/pom.xml there is no dependency on
> errai/pom.xml anymore ... as it was before
> or can you point me, where you see the dependency on parent pom ?
For example, the pom.xml at
https://github.com/errai/errai/blob/3.0_p/errai-bus/demos/stockdemo/pom.xml
should not have a <parent> entry.
We still need an aggregator pom for the demos (right now, at
https://github.com/errai/errai/blob/3.0_p/errai-bus/demos/pom.xml but later at
demos/pom.xml) but it will just have a <modules> section. The demos will not
point back to it as their parent.
> >> I *do* think we should develop a 'depchain' or 'BOM' type pom that can be
> >> imported. These would be useful for demos, archetypes, and anybody's
> >> end-user project.
> >> We should probably have a separate depchain for each appserver we support
> >> (as7, eap6, tomcat, jetty). We should design these depchains so the demo
> >> poms are as small
> >> as possible (unfortunately, we can't import plugin configurations, so they
> >> will be somewhat larger than what we have now).
>
> This is an interesting idea, yes we could have a BOM's, which could keep
> dependencies, but as you say.. still there must be plugin configurations
> and we need separated profiles. So we must be careful not to have in the end
> the configuration even harder, then now.
If we can build one depchain BOM per container type (JBoss AS 7, EAP 6, Tomcat,
Jetty), it could be as simple as defaulting to EAP 6 and listing the
alternatives in a comment in the demo poms. In this case, we wouldn't need
profiles at all.
> >> Finally +1 for stack POMs. This is what I started with the
> >> errai-javaee-all module. As far as I know it still works. Very helpful if
> >> users can pull in a single dependency and have a working setup on a given
> >> container.
>
> Yeah, I like this approach... the stack pom project as errai-javaee-all
> looks great and simple...
> On the other hand, do we want to introduce like stack projects for every
> "demo topic" ... or do you have any other suggestion how to differentiate
> between the stacks projects , other then
> the "demo topic" ?
> This can turn into having much more configuration overhead just because of
> demos...
My preference would be to make all the demo poms depend on the whole Errai
framework via errai-javaee-all (or a similar imported depchain pom). Ideally,
the demo poms will all be identical aside from artifactId and description.
> looking at errai/errai-javaee-all/pom.xml ... it keeps dependencies only
> so its practically the same as, what we can reach with BOM here...
>
> <dependencies>
> <dependency>
> <groupId>${groupId}</groupId>
> <artifactId>bom</artifactId>
> <version>${version}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> </dependencies>
>
>
> I would not care too much about dependencies here, as we can easily simplify
> it via BOM's or stack projects... as shown above, what keeps me concerned is
> how to simplify profiles & plugin configurations
> Do you have any ideas, how we could simply inherit or import those... ?
> with the idea behind to keep the actual demo poms tiny ?
I think for now, we're going to have to duplicate the plugin configurations
across all the demo poms. Although the duplication makes things harder for us,
I think it makes things easier for people approaching our project for the first
time. The best way to deal with the pain from our side would be to maintain a
single template pom and write a script that we can use to overwrite the demo
poms when we change the template.
Cheers,
Jonathan_______________________________________________
errai-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/errai-dev
