Generating application.xml for Enterprise Archive?

[Michael Schuetz]

Hi to all,

typical EAR file build by ShrinkWrap looks like this:

{code}

@Deployment
    public static Archive<?> getTestArchive() {
        final WebArchive war = ShrinkWrap.create(WebArchive.class, "test.war");
        final JavaArchive ejb = ShrinkWrap.create(JavaArchive.class, "test.jar")
                .addClasses(MyService.class, MyServiceBean.class);
        final EnterpriseArchive ear = ShrinkWrap.create(EnterpriseArchive.class,
                "test.ear")
                .setApplicationXML("application.xml")
                .addModule(war)
                .addModule(ejb);

        return ear;
    }

{code}

AFAIK it is required to set application.xml explicitely.

For most usecases generating application.xml (like maven ear plugin does) would probably be sufficient.

So, if you don't set application.xml, would be nice that ShrinkWrap generates it (or a generateApplicationXML method if you don't like automagic).

What do you think?

Thanks and regards

Michael

[jaikiran pai]

I have seen some posts which mention the "descriptors" project. Although I haven't looked into the details of that. Maybe we could have something like:

EnterpriseArchiveDescriptor applicationXml = Descriptors.create(EnterpriseArchive ear);
// similarly maybe for war and other types of archives

[Aslak Knutsen]

Yea, it's on our list of potential things to support with the help of the Descriptors project and ShrinkWrap listeners.

Via Listeners ShrinkWrap can keep track of changes to the Archive and keep the Descriptor in sync..

http://github.com/shrinkwrap/descriptors

[Aslak Knutsen]

jaikiran pai wrote:

I have seen some posts which mention the "descriptors" project. Although I haven't looked into the details of that. Maybe we could have something like:

EnterpriseArchiveDescriptor applicationXml = Descriptors.create(EnterpriseArchive ear);
// similarly maybe for war and other types of archives
 

Yea , that's what we're working for;  http://github.com/shrinkwrap/descriptors/blob/master/src/test/java/org/jboss/shrinkwrap/descriptor/spec/web/WebAppDefTest.java

It's just a bit hardcoded at the moment:  http://github.com/shrinkwrap/descriptors/blob/master/src/main/java/org/jboss/shrinkwrap/descriptor/api/Descriptors.java

[Michael Schuetz]

Thanks for the replies.

Pretty interesting the descriptor examples..

Michael

[Andrew Rubinger]

And the good news is that we're still looking for a contributor to further develop the existing prototype.  Anyone interested should get in touch and I'll write up a design requirements doc to kickoff discussion.

S,

ALR

[Guillaume Grossetie]

Are you still looking ?

If so just let me know, and I'd be pleased to help on the existing prototype...

Cheers,

Guillaume.

[Andrew Rubinger]

This is admitedly dragging on a bit due to priorities and resourcing, but we're keeping track of requirements here:

  https://community.jboss.org/docs/DOC-48532

S,

ALR

[Guillaume Grossetie]

Wow the project has a lot of history !

I think that the factory based API is a good https://community.jboss.org/wiki/ShrinkwrapDescriptorFactoryBasedAPIProposal / https://gist.github.com/aslakknutsen/1025597. From a user perspective I believe that keeping the Shrinkwrap “look and feel” is essential, this is why I prefer Aslak’s proposal.

The following page https://community.jboss.org/wiki/ShrinkwrapDescriptorAPIProposal lists the bad parts of the current API but I think it’s important to also list the good parts. This will help us to draw up a list of naming conventions and design rules to follow... and as I'm new to the project I will need these guidelines

Is this pull request https://github.com/shrinkwrap/descriptors/pull/90 stills revelant ?

Maybe we can split the work by XSDs / DTD https://community.jboss.org/wiki/ShrinkwrapDeploymentDescriptorsWiki and start sending PR into the prototype modules ?

Guillaume.

[Guillaume Grossetie]

I started playing with the PersistenceDescriptor to understand a little better the project. I also added some shortcut methods to see how the API will look and how can we implement them.

The current POC with mutable/immutable views in the master branch use parent/child node to navigate through the descriptor model but your comment on Ralf's PR is clearly in favor of a non hierarchical approch. Do you have settled if the new API will be "hierarchical" or not ?

Thanks,

Guillaume.