Maven plugins for vert.x

[Pid]

Hi,

I'm starting work on the long promised Maven plugins for vert.x and I'd
like to get some feedback and ideally some contributions from the folks
who've already done some work in this area.

As as aside: we have an increasing number of build related components,
so I'm strongly considering a new coordinate group for the build tools.


From reviewing the various discussions about Maven I think we need the
following maven modules:

- org.vert-x.build:maven-safetest-plugin:$version

Integration testing support, to ensure the classpath is applied in such
a way as to prevent vert.x from throwing the
"java.lang.IllegalStateException".

Adding provided+test scopes together, with all vert.x deps in provided
should do this (and is what the Gradle plugin does).

- org.vert-x.build:maven-runtime-plugin:$version

Again composes a classpath from the provided scope, but this time has
configuration for starting a verticle or a module.

- org.vert-x.build:maven-assembly-plugin:$version

Packaging a busmod.


Comments, ideas & discussion are very welcome. Contributions even more so.


p



--

[key:62590808]

[Oliver Rolle]

Hi,

I am pretty interested in vert.x + maven but I am a newbie to maven (start using maven 2 weeks ago) and I will not be much of a help. My newbie wish list for vert.x integration in maven:

• Vert.x module documentation: generate module wiki doc automatically
  
• Publishing of the vert.x modules

best regards
oli

[bytor99999]

For the assembly plugin. Would it just be an extension to the current maven-assembly plugin. We are using that for now and it was pretty easy, once you got it done once and had something you could copy and past.

Would that plugin have places to point where your verticles are? Instead of say a naming convention for location of those files. I think depending on the language you use for your verticle would make a difference on where you want to put those files. For instance, since we use Groovy, they aren't even in the maven src/main directory but directly off the root in a directory called /scripts.

Mark

[Paulo Lopes]

I've played around with vertx and maven on my pet project BSONEventBus. I do package my project as a module using the assembly plugin as follows:

<project ...>
    ...
    <version>v1.1</version>
    ...
    <dependencies>
        <dependency>
            <groupId>org.vert-x</groupId>
            <artifactId>vertx-core</artifactId>
            <version>1.3.1.final</version>
        </dependency>
        <dependency>
            <groupId>org.vert-x</groupId>
            <artifactId>vertx-lang-java</artifactId>
            <version>1.3.1.final</version>
        </dependency>
        <dependency>
            <groupId>org.vert-x</groupId>
            <artifactId>vertx-lang-groovy</artifactId>
            <version>1.3.1.final</version>
        </dependency>
        ...
    </dependencies>
    <build>
        <resources>
            <resource>
                <directory>src/main/resources</directory>
                <excludes>
                    <exclude>mod.json</exclude>
                </excludes>
                <filtering>false</filtering>
            </resource>
        </resources>
        <plugins>
            ...
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <appendAssemblyId>false</appendAssemblyId>
                    <finalName>mod</finalName>
                    <descriptors>
                        <descriptor>src/main/assembly/assembly.xml</descriptor>
                    </descriptors>
                    <attach>true</attach>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

full file: https://github.com/pmlopes/bson.vertx.eventbus/blob/master/pom.xml

And then my assembly.xml contains the following:

<assembly>
    <id>mod</id>
    <formats>
        <format>zip</format>
    </formats>
    <baseDirectory>target</baseDirectory>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <directory>${project.build.directory}</directory>
            <outputDirectory>${project.artifactId}-${project.version}/lib</outputDirectory>
            <includes>
                <include>*.jar</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>${project.basedir}/src/main/resources</directory>
            <outputDirectory>${project.artifactId}-${project.version}</outputDirectory>
            <includes>
                <include>mod.json</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>${project.basedir}</directory>
            <outputDirectory>${project.artifactId}-${project.version}</outputDirectory>
            <includes>
                <include>README.md</include>
            </includes>
        </fileSet>
    </fileSets>
</assembly>

Note that for the assembly to generate the correct path name I am setting the version variable with "v" + version. However i think this could just be fixed in the assembly.xml file to prepend "v" before the version property.

[froz3n]

Hi Pid,

Here's what I would like to see in the maven vert.x plugin:

1. The basic stuff: start and stop the server as well as a way to easily add and remove modules through the pom. Basically the similar to cargo, jetty, jboss or any other maven AS plugin. It could also be a good idea to ask the cargo plugin folks to get vert.x added to their great plugin (http://cargo.codehaus.org)

2. Have vert.x to standardize on an application structure, specially useful for the web layer but also convenient for any other future addition, such as OSGi , Spring, etc. This is also important for the client side for cases like WebJars  (recently released by James Ward, see http://www.webjars.org) that rely on standard directory structure for deps loading. I know that there has been some discussion on this recently but I'm not aware if there has been any final decision on the directory model to be used. If this is standardize then, the plugin that your starting to develop could also do the default type of packaging for vert.x. For any other type, falling back to the assembly plugin would do just fine.

I have not done any maven plugin development, but I'm willing to help. Just organize it, point me to the tickets and I'll dig in.

[wilsonjackson]

For what it's worth, I've been using the Maven failsafe plugin for integration tests (coupled with your junit annotations) and that works like a charm. I don't think it's necessary to build a vertx-specific plugin when failsafe works pretty well right out of the box. I haven't had any classpath issues with it.

One minor hurdle is performing tests on a module that relies on other modules. To do that, you need to inform vertx of the mod dir where it can download dependencies, and you have to shuttle your own module into that same directory so vertx can find it. Not too tough, but I wonder if it could be simplified.

I'd say the most trying aspect of the vertx/Maven combo for me has been packaging. I see some others here have spent some effort on using the assembly plugin, which looks promising. I kinda threw up my hands and used the ant-runner plugin to move stuff around.

[Pid]

On 26/01/2013 10:14, wilsonjackson wrote:
> For what it's worth, I've been using the Maven failsafe plugin for
> integration tests (coupled with your junit annotations) and that works
> like a charm. I don't think it's necessary to build a vertx-specific
> plugin when failsafe works pretty well right out of the box. I haven't
> had any classpath issues with it.

OK, that's good news. Would you be able to add an example showing how
that works to the (currently blank) JUnit Annotations wiki page for
Maven then please?

https://github.com/vert-x/vertx-junit-annotations/wiki/Using-Maven-with-vert.x-JUnit-Annotations

> One minor hurdle is performing tests on a module that relies on other
> modules. To do that, you need to inform vertx of the mod dir where it

> can download dependencies, /and/ you have to shuttle your own module

> into that same directory so vertx can find it. Not too tough, but I
> wonder if it could be simplified.

There's a system property to specify this in vert.x -Dvertx.mods.

The JUnit annotation code will also detect this. We found one issue
which I've fixed & will be in the next, imminent release.

> I'd say the most trying aspect of the vertx/Maven combo for me has been
> packaging. I see some others here have spent some effort on using the
> assembly plugin, which looks promising. I kinda threw up my hands and
> used the ant-runner plugin to move stuff around.

OK, so maybe packaging & copying resources is where we can improve things.


p

> --
>
>


--

[key:62590808]

[Brian Lalor]

On Jan 26, 2013, at 9:13 AM, Pid <p...@pidster.com> wrote:

>> I'd say the most trying aspect of the vertx/Maven combo for me has been
>> packaging. I see some others here have spent some effort on using the
>> assembly plugin, which looks promising. I kinda threw up my hands and
>> used the ant-runner plugin to move stuff around.
>
> OK, so maybe packaging & copying resources is where we can improve things.

I'm very happy with what I've been able to accomplish with the assembly plugin. I'll try to document that.

[Pid]

Can this be packaged as a module? There's a project called
maven-plugins[1], empty so far... contributions welcome.


p


1. https://github.com/vert-x/maven-plugins



--

[key:62590808]

[Brian Lalor]

As a module (of the vert.x variety), or as a Maven plugin? I believe it can actually be packaged and distributed as a Maven *artifact*.

Here's a Gist with the relevant config:

https://gist.github.com/4642746

mod.xml could be packaged up and included as a dependency for the assembly plugin, but that would only remove the need for creating a copy of mod.xml in your project; the boilerplate in the pom.xml would not really be simplified. There may be a better way to share assembly descriptors, but I don't have time to look into that right now.

[Pid]

On 26/01/2013 14:39, Brian Lalor wrote:
> On Jan 26, 2013, at 9:25 AM, Pid <p...@pidster.com> wrote:
>
>> On 26/01/2013 14:17, Brian Lalor wrote:
>>> On Jan 26, 2013, at 9:13 AM, Pid <p...@pidster.com> wrote:
>>>
>>>>> I'd say the most trying aspect of the vertx/Maven combo for me has been
>>>>> packaging. I see some others here have spent some effort on using the
>>>>> assembly plugin, which looks promising. I kinda threw up my hands and
>>>>> used the ant-runner plugin to move stuff around.
>>>>
>>>> OK, so maybe packaging & copying resources is where we can improve things.
>>>
>>> I'm very happy with what I've been able to accomplish with the assembly plugin. I'll try to document that.
>>
>> Can this be packaged as a module? There's a project called
>> maven-plugins[1], empty so far... contributions welcome.
>
> As a module (of the vert.x variety), or as a Maven plugin? I believe it can actually be packaged and distributed as a Maven *artifact*.

Maven thing, not a vert.x module; sorry.

> Here's a Gist with the relevant config:
>
> https://gist.github.com/4642746
>
> mod.xml could be packaged up and included as a dependency for the assembly plugin, but that would only remove the need for creating a copy of mod.xml in your project; the boilerplate in the pom.xml would not really be simplified. There may be a better way to share assembly descriptors, but I don't have time to look into that right now.

Anything that reduces the effort down some works.


p



--

[key:62590808]

[wilsonjackson]

I'd be glad to write some stuff up after I clean up my implementation. I also need to make sure it'll work with a one-off Verticle, as I've only been testing Modules up to this point.

Module assembly and integration testing in Maven seem like two separate issues to me, but they're also wrapped up together, because in order to run a module in a Vert.x instance it's got to be packaged correctly. So I guess whatever documentation goes on that page has to address both to an extent.

I've actually just been implementing the assembly plugin config blalors posted to replace my ghetto ant stuff. Thanks for that!

[bytor99999]

I did write a blog post showing how to use the assembly plugin for packaging your app.

Configuring Maven to build your vertx module

But it would be nice if a vert.x maven plugin had the same features but say in a simpler configuration. Maybe some defaults that do a particular convention of file/directory locations.

Mark

On Wednesday, January 23, 2013 12:12:59 AM UTC-8, Pid wrote:

[wilsonjackson]

Agreed, module packaging is the one thing I think could most cleanly be solved by a Maven plugin.

I'm curious what people think about conventions for module artifacts within a Maven build, since presumably these would be soft-enforced by an official plugin. I find myself organizing artifacts thusly:

target/vertx-mod/${build.finalName} - An exploded directory of the module; I set my finalName to the standard convention: ${project.groupId}.${project.artifactId}-v${project.version}

target/vertx-mod/${build.finalName}.zip - The zipped module

target/test-mods/${build.finalName}.zip - A copy of the zipped module for integration testing. This is the part I'm still doing with ant-run (haven't figured out a better way), and it's in its own directory because Vert.x needs to be able to install dependency modules.

[wilsonjackson]

By the by, I created a little example maven project demonstrating using failsafe. Whoever is interested can see it here: https://github.com/wilsonjackson/vertx-junit-annotations-maven-example

I'll try to parlay the meager doc here into a more robust version for the wiki. Eventually.

[Tim Fox]

They haven't been called 'busmods' for a very long time!

I strongly recommend that the standard application structure should be a
module, it's a lot cleaner and more self contained than running
verticles directly.

For larger projects, structure them as a set of modules.

Each module can correspond to a Maven project.

I'd be wary of blindly following a traditional Maven project structure.
Bear in mind that Maven was created in the Java world and is primarily a
tool for Java projects. In Java you generally have to compile classes
first before assembling them - this naturally leads to a project
structure where the source is kept in a different place to the build.

This is not true for scripting languages, and maintaining source in a
different place just adds extra complexity, imho.

For simple modules you hardly need a build tool at all. Just lay out
your module in your project directory and started editing your scripts
directly in there. No build phase needed at all. To run the module just
vertx runmod <mod_name> from the command line.

If you want to precompile stuff (e.g. Java or Groovy classes) the you'll
need a separate build task. But even here, Vert.x can handle the
compiling of .java files at runtime, so during development you can do
without the build phase.

[Pid]

That's the idea.

> For larger projects, structure them as a set of modules.
>
> Each module can correspond to a Maven project.
>
> I'd be wary of blindly following a traditional Maven project structure.
> Bear in mind that Maven was created in the Java world and is primarily a
> tool for Java projects. In Java you generally have to compile classes
> first before assembling them - this naturally leads to a project
> structure where the source is kept in a different place to the build.

I am aware of this.

> This is not true for scripting languages, and maintaining source in a
> different place just adds extra complexity, imho.

This would be aimed at Maven users. I'll look at other the languages to
see whether there's something we can provide that helps / is appropriate
for them.


p

> For simple modules you hardly need a build tool at all. Just lay out
> your module in your project directory and started editing your scripts
> directly in there. No build phase needed at all. To run the module just
> vertx runmod <mod_name> from the command line.
>
> If you want to precompile stuff (e.g. Java or Groovy classes) the you'll
> need a separate build task. But even here, Vert.x can handle the
> compiling of .java files at runtime, so during development you can do
> without the build phase.
>>
>>
>> Comments, ideas & discussion are very welcome. Contributions even
>> more so.
>>
>>
>> p
>>
>>
>>
>

--

[key:62590808]

[Tim Fox]

I don't think it would be a good idea to have one official project
structure for Maven users and another one for everyone else ;)

[Pid]

Maven is not particularly negotiable in that regard. Gradle is more
configurable, but the Maven standard for source layout is commonly used.


I don't think that recommending the Maven layout is necessarily
appropriate for Javascript for example, but I do think it would be
reasonable to recommend one layout for compile-at-runtime (where you
edit files inside the module structure) and compile-before-packaging
(where you use a build tool & are likely to want unit/integration test
support).


I agree that you hardly need a buildtool at all for the former, but
maybe we could provide a starter script (or gem, for Ruby, perhaps) that
zips up & creates the module structure. Seems like its worth looking at
anyway.

>> I'll look at other the languages to
>> see whether there's something we can provide that helps / is appropriate
>> for them.
>>
>>
>> p
>>
>>> For simple modules you hardly need a build tool at all. Just lay out
>>> your module in your project directory and started editing your scripts
>>> directly in there. No build phase needed at all. To run the module just
>>> vertx runmod <mod_name> from the command line.
>>>
>>> If you want to precompile stuff (e.g. Java or Groovy classes) the you'll
>>> need a separate build task. But even here, Vert.x can handle the
>>> compiling of .java files at runtime, so during development you can do
>>> without the build phase.
>>>>
>>>> Comments, ideas & discussion are very welcome. Contributions even
>>>> more so.
>>>>
>>>>
>>>> p
>>>>
>>>>
>>>>
>>
>

--

[key:62590808]

[Tim Fox]

Perhaps that's one way to do it. Have a switch when creating the project
structure "-traditional" which creates the project with separate source
and build directories.

Otherwise -modern to create a structure where you just edit stuff
directly in the module. Also worth bearing in mind that Vert.x does
support running .java source files directly, so for simple Java modules
don't really need a separate build stage either.

Forcing users to execute a build (even if its just pressing a button on
an IDE) would be rather annoying for projects that didn't need that step.

Another thing to think about, and this was discussed some time back in
this group. In Vert.x 2.0 you'll also be able to put modules that you
depend on _inside_ your module, i.e. we'll support nested modules - this
enables you to package up your module and all its deps in a single
runnable mod.zip.

So some support in the plugin for collecting deps into a module would be
good.

One final point - a lot of the functionality of the Maven plugin should
be reusable in a Gradle plugin or just in some Vert.x command line
tools, so it would be a good idea to develop it as set of helper classes
without any Maven dependencies.

You can then wrap them in a Maven plugin, or Gradle plugin or whatever.

Personally I wouldn't be much interested in using a Maven/Gradle plugin
but I would be interested in command line utilities that create a new
project structure etc, e.g.

vertx createProject foo -modern

[Pid]

This raises a thought; we should still publish the language
implementations as jars to Maven Central even if they are now downloaded
at runtime, as otherwise we'll end up jumping through hoops to configure
a classloader for IDEs...

> One final point - a lot of the functionality of the Maven plugin should
> be reusable in a Gradle plugin or just in some Vert.x command line
> tools, so it would be a good idea to develop it as set of helper classes
> without any Maven dependencies.

Agreed, that makes sense.

> You can then wrap them in a Maven plugin, or Gradle plugin or whatever.
>
> Personally I wouldn't be much interested in using a Maven/Gradle plugin
> but I would be interested in command line utilities that create a new
> project structure etc, e.g.
>
> vertx createProject foo -modern

That also makes sense.


p

>> I agree that you hardly need a buildtool at all for the former, but
>> maybe we could provide a starter script (or gem, for Ruby, perhaps) that
>> zips up & creates the module structure. Seems like its worth looking at
>> anyway.
>>
>>
>>
>>>> I'll look at other the languages to
>>>> see whether there's something we can provide that helps / is
>>>> appropriate
>>>> for them.
>>>>
>>>>
>>>> p
>>>>
>>>>> For simple modules you hardly need a build tool at all. Just lay out
>>>>> your module in your project directory and started editing your scripts
>>>>> directly in there. No build phase needed at all. To run the module
>>>>> just
>>>>> vertx runmod <mod_name> from the command line.
>>>>>
>>>>> If you want to precompile stuff (e.g. Java or Groovy classes) the
>>>>> you'll
>>>>> need a separate build task. But even here, Vert.x can handle the
>>>>> compiling of .java files at runtime, so during development you can do
>>>>> without the build phase.
>>>>>> Comments, ideas & discussion are very welcome. Contributions even
>>>>>> more so.
>>>>>>
>>>>>>
>>>>>> p
>>>>>>
>>>>>>
>>>>>>
>>
>

--

[key:62590808]

[Brian Lalor]

On Jan 30, 2013, at 5:07 AM, Pid <p...@pidster.com> wrote:

> This raises a thought; we should still publish the language
> implementations as jars to Maven Central even if they are now downloaded
> at runtime, as otherwise we'll end up jumping through hoops to configure
> a classloader for IDEs...

Absolutely. There are plenty of us who DO NOT WANT stuff to be downloaded at runtime. I don't trust any system that gives me a deployment artifact that is only partially complete.

[Brian Lalor]

On Jan 30, 2013, at 4:35 AM, Pid <p...@pidster.com> wrote:

>> I don't think it would be a good idea to have one official project
>> structure for Maven users and another one for everyone else ;)
>
> Maven is not particularly negotiable in that regard. Gradle is more
> configurable, but the Maven standard for source layout is commonly used.
>
>
> I don't think that recommending the Maven layout is necessarily
> appropriate for Javascript for example, but I do think it would be
> reasonable to recommend one layout for compile-at-runtime (where you
> edit files inside the module structure) and compile-before-packaging
> (where you use a build tool & are likely to want unit/integration test
> support).

What do you think the non-negotiable Maven layout is, exactly, and what do you object to?

A JS module would put its source in src/main/javascript; you could just use src/main/$LANGUAGE. This is a standard already supported by Maven. Properties files and other resources would go in src/main/resources. Stuff that is for tests go under src/test, and stuff for integration tests go under src/it. The separation of unit test and integration test code is to make running them separately easier.

[Tim Fox]

You don't have to have your modules downloaded at runtime if you don't
want. You can always pre-install them using vertx install (as discussed
before).

Going ahead more and more parts of Vert.x are going to be managed by the
community and exist as modules controlled by other entities. This is
essential for creating a vibrant ecosystem which will allow the project
to thrive.

The idea that everything should be controlled, checked and distributed
by a central project just doesn't scale. It's not the future.
>

[Brian Lalor]

On Feb 1, 2013, at 6:51 AM, Tim Fox <timv...@gmail.com> wrote:

>> Absolutely. There are plenty of us who DO NOT WANT stuff to be downloaded at runtime. I don't trust any system that gives me a deployment artifact that is only partially complete.
> You don't have to have your modules downloaded at runtime if you don't want. You can always pre-install them using vertx install (as discussed before).
>
> Going ahead more and more parts of Vert.x are going to be managed by the community and exist as modules controlled by other entities. This is essential for creating a vibrant ecosystem which will allow the project to thrive.
>
> The idea that everything should be controlled, checked and distributed by a central project just doesn't scale. It's not the future.

I'm talking deployments here. Don't make it hard for me to build a self-contained deployment artifact, and don't reinvent the wheel. I know when packaging my application what modules, languages, and libraries I need to run it. If you defer the retrieval of those artifacts to run-time then you risk various degrees of nondeterminism at start-up time. Is there access to the Internet from the server that's running the application? Is the artifact server down for maintenance? Did someone compromise the artifact server? All of these problems go away if you give me a self-contained package that never needs to reach out to an external resource to run, even if it's the first time. The WARs I build today will work after the zombie apocalypse because they're self-contained. It's best packaging system I've seen for any language/ecosystem. You should be looking to emulate that.

[Diego López León]

On Fri, Feb 1, 2013 at 8:51 AM, Tim Fox <timv...@gmail.com> wrote:
> On 01/02/13 11:33, Brian Lalor wrote:
>>
>> On Jan 30, 2013, at 5:07 AM, Pid <p...@pidster.com> wrote:
>>
>>> This raises a thought; we should still publish the language
>>> implementations as jars to Maven Central even if they are now downloaded
>>> at runtime, as otherwise we'll end up jumping through hoops to configure
>>> a classloader for IDEs...
>>
>> Absolutely. There are plenty of us who DO NOT WANT stuff to be downloaded
>> at runtime. I don't trust any system that gives me a deployment artifact
>> that is only partially complete.
>
> You don't have to have your modules downloaded at runtime if you don't want.
> You can always pre-install them using vertx install (as discussed before).

I think the feeling here is that some of us prefer to get all the
ecosystem of our systems managed by our build tool and even at
_packaging_ time. Maven, for java devs, became a somehow standard
these days, and something that the users of this tool have as a mojo
is like if some project is making its package, test and distribution
REALLY complicated, well, there is a chance that something may be
going wrong.

> Going ahead more and more parts of Vert.x are going to be managed by the
> community and exist as modules controlled by other entities. This is
> essential for creating a vibrant ecosystem which will allow the project to
> thrive.
>
> The idea that everything should be controlled, checked and distributed by a
> central project just doesn't scale. It's not the future.
>

It's possible that my previous statement may be tied to old paradigms,
but for the moment, I haven't seen the light :)

--
diego

[Tim Fox]

On 01/02/13 12:06, Brian Lalor wrote:
> On Feb 1, 2013, at 6:51 AM, Tim Fox <timv...@gmail.com> wrote:
>
>>> Absolutely. There are plenty of us who DO NOT WANT stuff to be downloaded at runtime. I don't trust any system that gives me a deployment artifact that is only partially complete.
>> You don't have to have your modules downloaded at runtime if you don't want. You can always pre-install them using vertx install (as discussed before).
>>
>> Going ahead more and more parts of Vert.x are going to be managed by the community and exist as modules controlled by other entities. This is essential for creating a vibrant ecosystem which will allow the project to thrive.
>>
>> The idea that everything should be controlled, checked and distributed by a central project just doesn't scale. It's not the future.
> I'm talking deployments here. Don't make it hard for me to build a self-contained deployment artifact, and don't reinvent the wheel. I know when packaging my application what modules, languages, and libraries I need to run it. If you defer the retrieval of those artifacts to run-time then you risk various degrees of nondeterminism at start-up time.

There is no non determinism at startup, if that's what you want. We
discussed in length in a different thread some weeks ago about how in
Vert.x 2.0 you will be able to package up your app and all it's
depending modules in a single module for deployment. Nothing has changed
there.

[Tim Fox]

On 01/02/13 12:08, Diego L�pez Le�n wrote:
> On Fri, Feb 1, 2013 at 8:51 AM, Tim Fox <timv...@gmail.com> wrote:
>> On 01/02/13 11:33, Brian Lalor wrote:
>>> On Jan 30, 2013, at 5:07 AM, Pid <p...@pidster.com> wrote:
>>>
>>>> This raises a thought; we should still publish the language
>>>> implementations as jars to Maven Central even if they are now downloaded
>>>> at runtime, as otherwise we'll end up jumping through hoops to configure
>>>> a classloader for IDEs...
>>> Absolutely. There are plenty of us who DO NOT WANT stuff to be downloaded
>>> at runtime. I don't trust any system that gives me a deployment artifact
>>> that is only partially complete.
>> You don't have to have your modules downloaded at runtime if you don't want.
>> You can always pre-install them using vertx install (as discussed before).
> I think the feeling here is that some of us prefer to get all the
> ecosystem of our systems managed by our build tool and even at
> _packaging_ time.

Yes you can do that as discussed before. Please read the previous
threads on this subject :)

[Bob McWhirter]

Yeah, the assembly plugin can use/fetch an assembly descriptor based on its GAV by just adding it as a dependency to the plugin configuration:

https://gist.github.com/4691525

Assuming that's published, then just reference the assembly type by name. 

[Trevor S]

Thanks for doing this Pid.

Tim, a maven archetype and plugin would have bootstrapped me in seconds in Intellij.   

Maven plugins have been created for everything under the sun and vert.x is just another.  while you say that vertx can download things at runtime and it can run .java files..thats nice and all, but most companies would rather have a well defined build process using the tool of their choice, dependencies pulled down at build time and a package created for deployment and a recognizable directory structure for their projects.

Build systems like maven have great ide integration, and being able to harness this for classpaths setup, running during development via the plugin, and of course build and packaging is huge.

There's nothing wrong with a maven way and a gradle way.  Its ultimately calling vertx anyways and autosetting the classpath for you, etc. from yuor maven pom or build.gradle.   Take grails-maven-plugin for a great  example - with the maven plugin i get full ide integration and standardization on our builds, dir structure so anyone in my company can jump onto the project and start immediately.

the maven plugin would mainly help folks who are using java and groovy.  thats alot of us and most large companies! :)

this has no effect on vertx and just helps alot of people get bootstrapped.  The only effect should be making sure that vertx is easily run in the manners the folks on this thread describe.

sorry if what i said is obvious now, but i wanted to be sure you understood the intent here - making vertx even more accessible to maven users.  This is a good thing!

On Wednesday, January 23, 2013 3:12:59 AM UTC-5, Pid wrote:

Hi,

I'm starting work on the long promised Maven plugins for vert.x and I'd
like to get some feedback and ideally some contributions from the folks
who've already done some work in this area.

As as aside: we have an increasing number of build related components,
so I'm strongly considering a new coordinate group for the build tools.


From reviewing the various discussions about Maven I think we need the
following maven modules:

- org.vert-x.build:maven-safetest-plugin:$version

Integration testing support, to ensure the classpath is applied in such
a way as to prevent vert.x from throwing the
"java.lang.IllegalStateException".

Adding provided+test scopes together, with all vert.x deps in provided
should do this (and is what the Gradle plugin does).

- org.vert-x.build:maven-runtime-plugin:$version

Again composes a classpath from the provided scope, but this time has
configuration for starting a verticle or a module.

- org.vert-x.build:maven-assembly-plugin:$version

Packaging a busmod.

[Tim Fox]

Trevor, have you seen this thread? https://groups.google.com/forum/?fromgroups=#!topic/vertx/zuYe7UVj8C4

I'm currently working on a standard Gradle build which should make things a lot easier for Gradle users, after that I'll do the same for Maven.

It's a WIP but it's already looking dead simple. The build creates and packages the artifacts. I've also improved the way tests are run. You can now create them as standard JUnit tests and Vert.x will make sure they are automagically run in the container.

[Brian Lalor]

On Feb 16, 2013, at 2:50 AM, Tim Fox <timv...@gmail.com> wrote:

 I've also improved the way tests are run. You can now create them as standard JUnit tests and Vert.x will make sure they are automagically run in the container.

This actually doesn't sound like a win.  There should be a distinction made between unit tests and integration tests.  Unit tests should be run outside of the container and should be focused on testing a single "unit" be it a verticle or a piece of supporting code.  Integration tests should be run in the container and can be used to test a configured system as a whole.  Well-written unit tests can be run very VERY quickly, but there's a lot of overhead in running integration tests.  If you go this route, please move the container integration to a phase that gets run after the unit tests have been run.  The Maven lifecycle goes like this:

• compile

• compile tests

• run tests

• package everything up

• run integration tests

• make sure the integration tests passed

• deploy the artifacts

[Tim Fox]

On 16/02/13 11:13, Brian Lalor wrote:

On Feb 16, 2013, at 2:50 AM, Tim Fox <timv...@gmail.com> wrote:

�I've also improved the way tests are run. You can now create them as standard JUnit tests and Vert.x will make sure they are automagically run in the container.

This actually doesn't sound like a win. �There should be a distinction made between unit tests and integration tests. �Unit tests should be run outside of the container and should be focused on testing a single "unit" be it a verticle or a piece of supporting code. �Integration tests should be run in the container and can be used to test a configured system as a whole.�

Yes, I was referring to integration tests - the current way of running them in the container is messy, it's a lot simpler now.

Unit tests can, of course, be run as normal outside the container.

Well-written unit tests can be run very VERY quickly, but there's a lot of overhead in running integration tests. �If you go this route, please move the container integration to a phase that gets run after�the unit tests have been run. �The Maven lifecycle goes like this:

� compile

� compile tests

� run tests

� package everything up

� run integration tests

� make sure the integration tests passed

� deploy the artifacts

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
�
�

[Tim Fox]

You can also write tests in JavaScript, Ruby etc, and use the standard Junit Assert API inside them as if it were a Java test. I did a bit of magic with a custom Junit runner so they can also be run inside the container, and you see the results in a standard Junit report as if they were Java tests. It's pretty cool.

So basically all the in container (integration tests) you can just write as normal Junit tests now, without any special annotations needed and no special proxies.

I haven't committed it yet, but will in the next few days.

[froz3n]

Pid, Tim, or anyone else, 

Please update the wiki with the final conclusions so that it is clear where all this discussion has actually lead.

https://github.com/vert-x/maven-plugins/wiki/Feature-Spec

[ramki]

 - Based on the spec (https://github.com/vert-x/maven-plugins/wiki/Feature-Spec) & the discussions, are these deliverables final?

   - Vertx Maven Archetype -- for creating vertx projects with appropriate structure.
   - Vertx Maven Plugin -- for building, testing, doc generation, running, packaging, installing, deploying & registering the modules.

If so, I can take a stab at it starting with the archetype if nobody is working on it.

 - Is there a home in GH for this work already?

-ramki

[Kutý Michael]

+1

Dne úterý, 19. února 2013 11:36:58 UTC+1 ramki napsal(a):

[Tim Fox]

Ramki-

I have put together a Gradle template project (see https://groups.google.com/forum/?fromgroups=#!topic/vertx/J6OZ8jYxDrc), the next thing on my list was to do the same for Maven.

I don't know much about Maven, so if you would like to take that task on, please go for it.

Once thing I don't quite understand yet, but I also know little about IDE plugins, is... if we create a standard Maven and Gradle build that shouldn't the Maven/Gradle plugin for Eclipse/IDEA just be able to read that and convert the targets into a form that can be run from the IDE? If so, I'm not sure why we need a specific IDE plugin for Vert.x....

[Diego López León]

@Tim,
speaking as IDEA user, it depends on what do u call standard maven
project. I give you an example, if u do a war project u will use the
maven-war-plugin, that sounds pretty standard but not all the
configuration fields are supported by IDEA[*].
Having said that, I don't think a specific IDE plugin is needed but a
friendly, for the maven case, pom.xml

[*]: for example, webapp resources filtering is not yet supported
http://youtrack.jetbrains.com/issue/IDEA-25934

> --
> You received this message because you are subscribed to the Google Groups
> "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vertx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
diego

[ramki]

On Tuesday, 19 February 2013 18:47:03 UTC+5:30, Tim Fox wrote:

I have put together a Gradle template project (see https://groups.google.com/forum/?fromgroups=#!topic/vertx/J6OZ8jYxDrc), the next thing on my list was to do the same for Maven.

Will work based on that.
 

I don't know much about Maven, so if you would like to take that task on, please go for it.

Ok, I'm going for Maven Archetype first.
 

Once thing I don't quite understand yet, but I also know little about IDE plugins, is... if we create a standard Maven and Gradle build that shouldn't the Maven/Gradle plugin for Eclipse/IDEA just be able to read that and convert the targets into a form that can be run from the IDE? If so, I'm not sure why we need a specific IDE plugin for Vert.x....

While Maven supports almost all modern languages, I'm not sure if supports building for target IDEs for all those languages. For java, we just need to run `mvn eclipse:eclipse`. It generates the eclipse .project, .classpath... Just open eclipse, import the project and start coding away.

One other way you can do in eclipse is the way you mentioned. Once you have maven eclipse plugin installed, you can just import a maven project directly into eclipse.

-ramki
 

[p...@pidster.com]

On 19 Feb 2013, at 10:37, ramki <ram...@gmail.com> wrote:

 - Based on the spec (https://github.com/vert-x/maven-plugins/wiki/Feature-Spec) & the discussions, are these deliverables final?

   - Vertx Maven Archetype -- for creating vertx projects with appropriate structure.
   - Vertx Maven Plugin -- for building, testing, doc generation, running, packaging, installing, deploying & registering the modules.

If so, I can take a stab at it starting with the archetype if nobody is working on it.

 - Is there a home in GH for this work already?

Please send PRs to the repo you refer to above.

p

--

[ramki]

 - Based on the spec (https://github.com/vert-x/maven-plugins/wiki/Feature-Spec) & the discussions, are these deliverables final?

   - Vertx Maven Archetype -- for creating vertx projects with appropriate structure.

Initial version of this is done. Still have some work to do like adding dependencies and making the created project compile! :)

But thought would share it early and take some feedback from you guys.

https://github.com/sramki/maven-archetype-vertx
 

   - Vertx Maven Plugin -- for building, testing, doc generation, running, packaging, installing, deploying & registering the modules.

 - Is there a home in GH for this work already?

Please send PRs to the repo you refer to above.

Will do that once its clean and complete. 

-ramki

[froz3n]

Ramki,

Very nice. Just one litle thing, could you rename it to vertx-maven-archtype instead? I nowadays names of plugins and archtypes always start with the intended execution context, in this case vertx. For example, JBoss archtype are: jboss-jaaee-webap-archtype or jboss-html5-mobile-archetype

You can check this trend in the maven archtype catalog:

http://repo1.maven.org/maven2/archetype-catalog.xml 

Great work. I'm working on a prototype for the vertx-maven-plugin (based on some work previously done) and soon I'll marry your work with it.

[Tim Fox]

Great! I will try this out tomorrow

[ramki]

On Thursday, 21 February 2013 00:36:12 UTC+5:30, froz3n wrote:

Ramki,

Very nice. Just one litle thing, could you rename it to vertx-maven-archtype instead?

This is done. I will change the repo name when we move it to our maven-plugins repo.
 

Great work. I'm working on a prototype for the vertx-maven-plugin (based on some work previously done) and soon I'll marry your work with it.

Sure. Are you planning to support stuff like building, testing, doc generation, running, packaging, installing, deploying & registering the modules in vertx-maven-plugin?

-ramki

[Tim Fox]

Yep. Any Maven build needs to support all that stuff.

Guys, however you do this, can you please make sure it does the same things as https://github.com/vert-x/vertx-gradle-template with the same target names.

I want the developer experience to be consistent for both Maven and Gradle users.

 

-ramki

[Kutý Michael]

+1 same naming for both build tools please, its good for understand 

Dne čtvrtek, 21. února 2013 8:28:37 UTC+1 Tim Fox napsal(a):

[ramki]

On Wednesday, 20 February 2013 23:02:02 UTC+5:30, ramki wrote:

 - Based on the spec (https://github.com/vert-x/maven-plugins/wiki/Feature-Spec) & the discussions, are these deliverables final?

   - Vertx Maven Archetype -- for creating vertx projects with appropriate structure.

Initial version of this is done. Still have some work to do like adding dependencies and making the created project compile! :)

The generated project now has the required deps and both main & test compiles fine. The tests do not run ok though.

Tim,

The tests throw an exception saying deploymentId cannot be null. What should I do for this?

-ramki

 

[ramki]

On Thursday, 21 February 2013 22:49:21 UTC+5:30, ramki wrote:

The tests throw an exception saying deploymentId cannot be null. What should I do for this?

Any pointers on the "deploymentId cannot be null" exception? Thats the only thing I'm stuck with currently.

Would it because the module was not packaged as a zip or is not deployed yet?

What does this line mean: container.deployModule("maven:${groupId}:${artifactId}:${version}-SNAPSHOT"?

maven keyword there will look for it in the public maven repository or local repo or just current build's target dir?

 

https://github.com/sramki/maven-archetype-vertx

-ramki

[Tim Fox]

On Friday, 22 February 2013 09:21:35 UTC, ramki wrote:

On Thursday, 21 February 2013 22:49:21 UTC+5:30, ramki wrote:

The tests throw an exception saying deploymentId cannot be null. What should I do for this?

Any pointers on the "deploymentId cannot be null" exception? Thats the only thing I'm stuck with currently.

What are you doing when you get that?

 

Would it because the module was not packaged as a zip or is not deployed yet?

What does this line mean: container.deployModule("maven:${groupId}:${artifactId}:${version}-SNAPSHOT"?

Looks old to me. Can you pull from vertx-gradletemplate again? 

[ramki]

On Friday, 22 February 2013 15:01:44 UTC+5:30, Tim Fox wrote:

The tests throw an exception saying deploymentId cannot be null. What should I do for this?

Any pointers on the "deploymentId cannot be null" exception? Thats the only thing I'm stuck with currently.

What are you doing when you get that?

I'm just doing a `mvn test`.

 

Would it because the module was not packaged as a zip or is not deployed yet?

What does this line mean: container.deployModule("maven:${groupId}:${artifactId}:${version}-SNAPSHOT"?

Looks old to me. Can you pull from vertx-gradletemplate again? 

I will do that and let you know.

-ramki

 

https://github.com/sramki/maven-archetype-vertx

-ramki

[Tim Fox]

On 22/02/13 09:48, ramki wrote:

On Friday, 22 February 2013 15:01:44 UTC+5:30, Tim Fox wrote:

The tests throw an exception saying deploymentId cannot be null. What should I do for this?

Any pointers on the "deploymentId cannot be null" exception? Thats the only thing I'm stuck with currently.

What are you doing when you get that?

I'm just doing a `mvn test`.

A bit more info. stacktrace etc would be helpful.

 

Would it because the module was not packaged as a zip or is not deployed yet?

What does this line mean: container.deployModule("maven:${groupId}:${artifactId}:${version}-SNAPSHOT"?

Looks old to me. Can you pull from vertx-gradletemplate again? 

I will do that and let you know.

-ramki

 

https://github.com/sramki/maven-archetype-vertx

-ramki

--

[ramki]

On Friday, 22 February 2013 15:19:46 UTC+5:30, Tim Fox wrote:

On 22/02/13 09:48, ramki wrote:

On Friday, 22 February 2013 15:01:44 UTC+5:30, Tim Fox wrote:

The tests throw an exception saying deploymentId cannot be null. What should I do for this?

Any pointers on the "deploymentId cannot be null" exception? Thats the only thing I'm stuck with currently.

What are you doing when you get that?

I'm just doing a `mvn test`.

A bit more info. stacktrace etc would be helpful.

Sorry, here is the output of mvn test:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.foo.bar.test.integration.java.InContainerTest
Feb 22, 2013 4:04:18 PM org.vertx.java.core.logging.impl.JULLogDelegate error
SEVERE: Module maven:com.foo.bar:baz:1.0-SNAPSHOT not found in any repositories
Test failed: deploymentID should not be null
java.lang.AssertionError: deploymentID should not be null
    at org.junit.Assert.fail(Assert.java:93)
    at org.junit.Assert.assertTrue(Assert.java:43)
    at org.junit.Assert.assertNotNull(Assert.java:526)
    at org.vertx.testtools.VertxAssert.assertNotNull(VertxAssert.java:236)
    at com.foo.bar.test.integration.java.InContainerTest$1.handle(InContainerTest.java:44)
    at com.foo.bar.test.integration.java.InContainerTest$1.handle(InContainerTest.java:41)
    at org.vertx.java.platform.impl.DefaultPlatformManager$9$1.run(DefaultPlatformManager.java:413)
    at org.vertx.java.core.impl.Context$1.run(Context.java:126)
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:366)
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:290)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88)
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.916 sec <<< FAILURE!

Results :

Failed tests:   com.foo.bar.test.integration.java.InContainerTest: deploymentID should not be null

Tests run: 4, Failures: 1, Errors: 0, Skipped: 0
-------------------------------------------------------
 

[Tim Fox]

This is just a test assertion failing. You've written a test and it includes an assert that the deployment id is not null. In this case the deployment id is null so it fails.

Deployment id would be null if the deployment failed.

[ramki]

On Friday, 22 February 2013 16:22:52 UTC+5:30, Tim Fox wrote:

On 22/02/13 10:37, ramki wrote:

This is just a test assertion failing. You've written a test and it includes an assert that the deployment id is not null. In this case the deployment id is null so it fails.

Deployment id would be null if the deployment failed.

And thats why I was trying to figure out whats happening when you do container.deployModule("maven:..."). Does it look for module in maven repository or zip file in the build directory or just loading the compiled classes...

Anyway, I will update the source from vertx-gradle-template and try it out first.

-ramki
 

[Tim Fox]

On 22/02/13 11:38, ramki wrote:

On Friday, 22 February 2013 16:22:52 UTC+5:30, Tim Fox wrote:

On 22/02/13 10:37, ramki wrote:

This is just a test assertion failing. You've written a test and it includes an assert that the deployment id is not null. In this case the deployment id is null so it fails.

Deployment id would be null if the deployment failed.

And thats why I was trying to figure out whats happening when you do container.deployModule("maven:..."). Does it look for module in maven repository or zip file in the build directory or just loading the compiled classes...

Basically that's how you deploy a Vert.x module programmatically. The argument is the module name. (maven:$GROUP_ID:$ARTIFACT_ID:$VERSION for a maven one).

Vert.x looks for modules in the local 'mods' dir (or $VERTX_MODS if that is set)

The test target should depend on the copyMod target (see Gradle build), so by the time the test target is run the module should already be in the local mods directory.

If you're getting a deployment failed it probably means it can't find the module (the log output should tell you more information) which probably means you haven't built it into the local mods directory.

Btw, why don't you come onto IRC? Would be much easier than using the group :)

[Tim Fox]

Ramki-

I am taking a look at your archetype - could you provide some more information on how to actually use it?

Please don't assume I have _any_ Maven understanding!

(I have read your README.md but didn't really parse it)

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

[ramki]

On Friday, 22 February 2013 18:19:51 UTC+5:30, Tim Fox wrote:

I am taking a look at your archetype - could you provide some more information on how to actually use it?

Sure Tim.

Archetypes are nothing but a meta-project output of which is your actual project with directories & files automatically created to jump start development. What I have put together is this meta-project like vertx-gradle-template.

With my zero understanding of Gradle, vertx-gradle-template is template project which users copy into their directories and rename the directories, files & package names per their need... For Maven projects you just use this Archetype it will create the directory, files & package names all based on the user input. There is no renaming of dirs, files...

So to start with you need to compile and deploy the archetype in your machine and then start using it for creating projects. Once we get the archetype into a central repository like ibiblio or maven central..., we wont have to compile & deploy the archetype in local machine. Until then here are the steps to follow.

I use linux and so I'm following the steps that I would execute in linux. Also I do not use any IDE for maven related stuff. So, sorry, all command lines only.

I'm assuming you have maven installed already, if not you can follow the steps here: http://maven.apache.org/download.cgi

Step 1: $ git clone https://github.com/sramki/maven-archetype-vertx.git

Step 2: $ cd maven-archetype-vertx
Note: You can now `ls -lR` to see the directories and files in them. The structure inside src/main/resources/archetype-resources would be exactly like the vertx-gradle-template project.

Step 3: $ mvn clean deploy;
Note: the above command compiles, packages and deploys your archetype in a temporary local repository (/tmp/mvn-repo). If you want to change the /tmp/mvn-repo path, change it in the pom.xml.

Thats all is the work with Archetype project.

Now, to create a project with the archetype.

Step 1: $ cd ~/

Note: Before you jump to next step, take a deep breath! :) Couple of things to know. 1) This step would not be this scary when you have the archetype deployed in common repository. 2) No typos allowed and its case-sensitive! :)

Step 2: $ mvn archetype:generate -DarchetypeRepository=file:///tmp/mvn-repo/ -DarchetypeGroupId=org.vertx.build  -DarchetypeArtifactId=vertx-maven-archetype -DarchetypeVersion=2.0 -DgroupId=com.foo.bar -DartifactId=baz -Dversion=1.0

Note the above command creates a project called baz (artifactId) under the com.foo.bar (groupId) and sets the version to 1.0. All the internal source and test files will be with the package name com.foo.bar. You can change groupId, artifactId and version to whatever you want. Just make sure the version is x.x and not something like x.x-SNAPSHOT...

Step 3: cd baz
Step 4: mvn clean compile test
Note: the above command will compile and run the tests in the newly created baz project.

Hope this is a good start and would not have any parse failures. Let me know if you want me to elaborate on something.

-ramki

[ramki]

On Friday, 22 February 2013 17:16:01 UTC+5:30, Tim Fox wrote:

This is just a test assertion failing. You've written a test and it includes an assert that the deployment id is not null. In this case the deployment id is null so it fails.

Deployment id would be null if the deployment failed.

And thats why I was trying to figure out whats happening when you do container.deployModule("maven:..."). Does it look for module in maven repository or zip file in the build directory or just loading the compiled classes...

The test target should depend on the copyMod target (see Gradle build), so by the time the test target is run the module should already be in the local mods directory.

Oh ok. Thats going to be the responsibility of our yet to be done vertx-maven-plugin. The plugin will manage the phases and the deps between them.

So, now I will update the archetype with the latest changes that you have done in vertx-gradle-template and submit a pull request to maven-plugins repo.

 

Btw, why don't you come onto IRC? Would be much easier than using the group :)

I used it about 15 years ago! :) Anyways will IRC in the future if the conversation will be long enough.

-ramki

[Tim Fox]

the Vert.x IRC channel is where it all happens! ;)

[froz3n]

On Friday, February 22, 2013 10:16:17 AM UTC-5, ramki wrote:

On Friday, 22 February 2013 17:16:01 UTC+5:30, Tim Fox wrote:

This is just a test assertion failing. You've written a test and it includes an assert that the deployment id is not null. In this case the deployment id is null so it fails.

Deployment id would be null if the deployment failed.

And thats why I was trying to figure out whats happening when you do container.deployModule("maven:..."). Does it look for module in maven repository or zip file in the build directory or just loading the compiled classes...

The test target should depend on the copyMod target (see Gradle build), so by the time the test target is run the module should already be in the local mods directory.

Oh ok. Thats going to be the responsibility of our yet to be done vertx-maven-plugin. The plugin will manage the phases and the deps between them.

So, now I will update the archetype with the latest changes that you have done in vertx-gradle-template and submit a pull request to maven-plugins repo.

Tim, help me here. I was just trying to deploy using the deployModule and in fact, it will look for modules in maven as requested. But the vertx2-mods is only available in on github, correct? Is that a maven repo as well? Or, how can I access those modules? is there something like github:group_id:artifact_id:version?

In addition, the focus of a vertx maven plugin is to deploy the verticle or the module being developed, not the ones that are available through repos. So, shouldn't I be using the deployModuleFromZip?

Ramki, I had a quick look into the archtype and it does not seem to include the necessary directory structure for a module. If not, could you use the maven-assembly-plugin for it? I think blalor had a gist somewhere... yeap... here: https://gist.github.com/blalor/4642746 

Notice that a lib directory as well as other directories might be required in order to build the module. 

Tim, did the module directory structure changed for Vertx 2?

[Tim Fox]

On 22/02/13 23:37, froz3n wrote:

On Friday, February 22, 2013 10:16:17 AM UTC-5, ramki wrote:

On Friday, 22 February 2013 17:16:01 UTC+5:30, Tim Fox wrote:

This is just a test assertion failing. You've written a test and it includes an assert that the deployment id is not null. In this case the deployment id is null so it fails.

Deployment id would be null if the deployment failed.

And thats why I was trying to figure out whats happening when you do container.deployModule("maven:..."). Does it look for module in maven repository or zip file in the build directory or just loading the compiled classes...

The test target should depend on the copyMod target (see Gradle build), so by the time the test target is run the module should already be in the local mods directory.

Oh ok. Thats going to be the responsibility of our yet to be done vertx-maven-plugin. The plugin will manage the phases and the deps between them.

So, now I will update the archetype with the latest changes that you have done in vertx-gradle-template and submit a pull request to maven-plugins repo.

Tim, help me here.

I recommend looking at https://github.com/vert-x/vertx-gradle-template and basing it on that - it should answer most of your questions. There is documentation in there that explains what most of the main actions do. We basically need equivalents.

I was just trying to deploy using the deployModule and in fact, it will look for modules in maven as requested.

You mean you're writing the equivalent of the 'runMods' task, which calls deployModule?

But the vertx2-mods is only available in on github, correct? Is that a maven repo as well?

I guess you missed the discussion(s) about module repos ;) We currently support all Maven repos (e.g. Nexus, Maven Central and bintray). The current vert.x 2.0 module snapshots are all in oss.sonatype

Or, how can I access those modules? is there something like github:group_id:artifact_id:version?

The module name (if stored in maven) is maven:group_id:artifact_id:version - from that and the repos.txt it knows where to get it from. All you need to do is call deployModule like the gradle script.

In addition, the focus of a vertx maven plugin is to deploy the verticle or the module being developed, not the ones that are available through repos. So, shouldn't I be using the deployModuleFromZip?

No. The build creates the module into the local 'mods' directory. This is the default place where modules get installed. When deploying a module Vert.x first looks in the mods directory, if it locates it it deploys it, if not it tries to install it from a repo.

Ramki, I had a quick look into the archtype and it does not seem to include the necessary directory structure for a module. If not, could you use the maven-assembly-plugin for it? I think blalor had a gist somewhere... yeap... here: https://gist.github.com/blalor/4642746 

Notice that a lib directory as well as other directories might be required in order to build the module. 

Tim, did the module directory structure changed for Vertx 2?

Yes. Just unzip one of the Vert.x 2.0 modules and you will see.

[ramki]

Ramki, I had a quick look into the archtype and it does not seem to include the necessary directory structure for a module. If not, could you use the maven-assembly-plugin for it? I think blalor had a gist somewhere... yeap... here: https://gist.github.com/blalor/4642746 

This is done now. But few catches with it. In Maven, as you would know, packaging happens after tests but in our project tests depend on packaging first. Packaging (using assembly.xml) is the one which creates the zip file.  So we either have to skip the tests (-DMaven.test.skip=true) or vertx-maven-plugin should create the classes, zip them and then run the tests and then package...

 

Notice that a lib directory as well as other directories might be required in order to build the module. 

I don't think lib directory is a requirement. The module should be a zip file and unzipping it should result in mods/<package_name...>/... I have it working with vertx runmod with this structure. Isn't that ok?

[wilsonjackson]

On Wednesday, February 27, 2013 8:47:02 AM UTC-8, ramki wrote:

This is done now. But few catches with it. In Maven, as you would know, packaging happens after tests but in our project tests depend on packaging first. Packaging (using assembly.xml) is the one which creates the zip file.  So we either have to skip the tests (-DMaven.test.skip=true) or vertx-maven-plugin should create the classes, zip them and then run the tests and then package...

Why wouldn't you just use the Maven Failsafe plugin? Failsafe runs an integration-tests phase after packaging, which is where in-container testing should be done, anyhow. Letting Surefire run your in-container tests before packaging also means you can't segregate unit tests from integration tests (not easily, anyhow).

I had hoped to be able to contribute to this effort as well, but my project that was using vert.x fell through and as a result I have no time available. I'm still very much interested in this project, though, and I'm just looking for places where the vert.x model will fit... it's so fun to use!

[froz3n]

A first prototype version is available at:

https://github.com/crazyfrozenpenguin/vertx-maven-plugin

A sample project that makes use of it is available at:

https://github.com/crazyfrozenpenguin/vertx-maven-plugin-test

As you will notice, I made use of the work made by rhart, for a older vertx-maven-plugin. 

Hopefully he will accepts my changes once I ask him to.

To deploy as a zip, all you have to do is to add the extension to the "moduleName" property. For example:

<moduleName>${project.artifactId}-${project.version}-mod.zip</moduleName>

This should work, but unfortunately I was not able to test it since it there is an issue with the zip module deployment in OSX.

Ramki, please notice that the test is not yet making use of your archtype. Notice that I have used the assembly plugin to create a zipped module and a uncompressed module in the target directory. The user can then choose which one he would like to use. Also, the target directory is by default the vertx modules directory.

Have a go and let me know of any issues, thoughts and improvements. This is just a first prototype.

[Tim Fox]

Hi froz3n,

It's a good start. Some comments:

Template:

1. I'm not sure I understand the different between start and run. Can you clarify?
2. stop - is this necessary? Won't CTRL-C do?
3. Verticles - I am _really_ trying to get away from the idea of users deploying apps as straight verticles. This is almost always a bad idea. We should be pushing a standard application setup and that should be a module. I.e. users should always create their apps as modules. Consequently I think all the stuff about packaging/running verticles should be removed from the plugin. (This will also make things a lot simpler!). This is the way the vertx-gradle-template has been designed (it's all about modules), and I think we should be consistent with the Maven plugin too.
4. <configuration/> I think all (?) of these options can go since they're all related to deploying verticles not modules. (With the possible exception of config). Again, I recommend taking a look at the run target in the standard gradle template for how to model this.

Test project:

1. Related to above... The test project creates a verticle. We should be pushing modules not verticles.
2. No tests. One of the big things about the standard templates is they make in-container testing very easy via the new testtools project. We should have examples of in container tests here (integration tests) in the same way as the Gradle template has them.
3. Not polyglot. The test project should have examples of tests/code written in different languages.

--

[froz3n]

Template:

1. I'm not sure I understand the different between start and run. Can you clarify?

In maven, in order to build your app you do:

mvn clean install

This will go through all the maven phases ( see here for more info http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)

The start goal starts in daemon mode and ensures that vert.x will not block the maven phase progress.

The run goal is just a super set of start goal that runs in non-daemon mode and is simply used for convenience. Basically, it allows the user to quickly run it's app with the current maven settings without having to run the full maven phases. In this mode, you will have to do a CTRL-C to kill maven/vert.x

2. stop - is this necessary? Won't CTRL-C do?

When in daemon mode, if you don't use it, then vert.x will keep running until the end of the maven build process.

 

3. Verticles - I am _really_ trying to get away from the idea of users deploying apps as straight verticles. This is almost always a bad idea. We should be pushing a standard application setup and that should be a module. I.e. users should always create their apps as modules. Consequently I think all the stuff about packaging/running verticles should be removed from the plugin. (This will also make things a lot simpler!). This is the way the vertx-gradle-template has been designed (it's all about modules), and I think we should be consistent with the Maven plugin too.

Yeap, not a problem, I will remove it. Although, and in my humble opinion, I often find myself wanting to quickly deploy a side verticle in order to do some proof of concept.

4. <configuration/> I think all (?) of these options can go since they're all related to deploying verticles not modules. (With the possible exception of config). Again, I recommend taking a look at the run target in the standard gradle template for how to model this.

I had a look in it, but I will look again in order to see if I'm missing something (I know very litle about Gradle and maybe I need to take some time to go through a good introduction). I did notice that it's only deploying modules. I initially thought this was strange but now I understand why.

 

Test project:

1. Related to above... The test project creates a verticle. We should be pushing modules not verticles.

Yes, It was defaulted to verticle. But I can convert it to modules. Unfortunately, there are issues with the maven harness test lib and maven3 and testing it has become more work than I initially expected. Instead I've provided a simple side example that can be easily adapted to any user needs. It was just an example.

 

2. No tests. One of the big things about the standard templates is they make in-container testing very easy via the new testtools project. We should have examples of in container tests here (integration tests) in the same way as the Gradle template has them.

Yes, Ramki archtype should include the vertx junit annotation. Also, the user is free to add the tests it requires. I can add an example. For example, run selenium tests during integration test phase.

 

3. Not polyglot. The test project should have examples of tests/code written in different languages.

True, as of yet I did not had the time to test it with all available languages. That's still to be added. If it counts, I did test with a mod-lang-scala verticle to,  so, I guess that it is at wee polyglot! ;-)

[Tim Fox]

On 28/02/13 14:14, froz3n wrote:

Template:

1. I'm not sure I understand the different between start and run. Can you clarify?

In maven, in order to build your app you do:

mvn clean install

This will go through all the maven phases ( see here for more info http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)

The start goal starts in daemon mode and ensures that vert.x will not block the maven phase progress.

The run goal is just a super set of start goal that runs in non-daemon mode and is simply used for convenience. Basically, it allows the user to quickly run it's app with the current maven settings without having to run the full maven phases. In this mode, you will have to do a CTRL-C to kill maven/vert.x

I still don't follow. The purpose of a run target is just to run the current module as if you have typed vertx runmod at the command line, but using the dependencies from the build. Why would we need a start target too?

2. stop - is this necessary? Won't CTRL-C do?

When in daemon mode, if you don't use it, then vert.x will keep running until the end of the maven build process.

The purpose of run is to run until you stop it.

 

3. Verticles - I am _really_ trying to get away from the idea of users deploying apps as straight verticles. This is almost always a bad idea. We should be pushing a standard application setup and that should be a module. I.e. users should always create their apps as modules. Consequently I think all the stuff about packaging/running verticles should be removed from the plugin. (This will also make things a lot simpler!). This is the way the vertx-gradle-template has been designed (it's all about modules), and I think we should be consistent with the Maven plugin too.

Yeap, not a problem, I will remove it. Although, and in my humble opinion, I often find myself wanting to quickly deploy a side verticle in order to do some proof of concept.

Sure, verticles are fine for writing trivial small scripts, but the templates are designed for people writing projects which, by definition, are non trivial. If you're just writing a 3 line web server you don't need a build script at all! Just echo <code> > app.js; vertx run app.js

4. <configuration/> I think all (?) of these options can go since they're all related to deploying verticles not modules. (With the possible exception of config). Again, I recommend taking a look at the run target in the standard gradle template for how to model this.

I had a look in it, but I will look again in order to see if I'm missing something (I know very litle about Gradle and maybe I need to take some time to go through a good introduction). I did notice that it's only deploying modules. I initially thought this was strange but now I understand why.

 

Test project:

1. Related to above... The test project creates a verticle. We should be pushing modules not verticles.

Yes, It was defaulted to verticle. But I can convert it to modules. Unfortunately, there are issues with the maven harness test lib and maven3 and testing it has become more work than I initially expected. Instead I've provided a simple side example that can be easily adapted to any user needs. It was just an example.

I'm not sure I understand what you mean.

 

2. No tests. One of the big things about the standard templates is they make in-container testing very easy via the new testtools project. We should have examples of in container tests here (integration tests) in the same way as the Gradle template has them.

Yes, Ramki archtype should include the vertx junit annotation.

No please don't. Vert.x junit annotations are deprecated. The new build has a _much_ simpler way to run tests. Take a look at the Gradle build for examples.

Also, the user is free to add the tests it requires. I can add an example. For example, run selenium tests during integration test phase.

Yes please. The purpose of the Maven template project is to provide a template that users can adapt for their own modules. Consequently it's important that we show them how to write tests in different languages. Again, see the Gradle template for examples. You should just be able to copy and paste.

 

3. Not polyglot. The test project should have examples of tests/code written in different languages.

True, as of yet I did not had the time to test it with all available languages.

Just copy and paste from the Gradle project

That's still to be added. If it counts, I did test with a mod-lang-scala verticle to,

Scala is not a supported Vert.x language yet, so best not to put that in yet!

[froz3n]

Tim,

On Thursday, February 28, 2013 9:26:48 AM UTC-5, Tim Fox wrote:

On 28/02/13 14:14, froz3n wrote:

Template:

1. I'm not sure I understand the different between start and run. Can you clarify?

In maven, in order to build your app you do:

mvn clean install

This will go through all the maven phases ( see here for more info http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)

The start goal starts in daemon mode and ensures that vert.x will not block the maven phase progress.

The run goal is just a super set of start goal that runs in non-daemon mode and is simply used for convenience. Basically, it allows the user to quickly run it's app with the current maven settings without having to run the full maven phases. In this mode, you will have to do a CTRL-C to kill maven/vert.x

I still don't follow. The purpose of a run target is just to run the current module as if you have typed vertx runmod at the command line, but using the dependencies from the build. Why would we need a start target too?

How do you do a CTRL-C when building in a Jenkins or Hudson server?

2. stop - is this necessary? Won't CTRL-C do?

When in daemon mode, if you don't use it, then vert.x will keep running until the end of the maven build process.

The purpose of run is to run until you stop it.

Again, CTRL-C is not sufficient.

 

 

3. Verticles - I am _really_ trying to get away from the idea of users deploying apps as straight verticles. This is almost always a bad idea. We should be pushing a standard application setup and that should be a module. I.e. users should always create their apps as modules. Consequently I think all the stuff about packaging/running verticles should be removed from the plugin. (This will also make things a lot simpler!). This is the way the vertx-gradle-template has been designed (it's all about modules), and I think we should be consistent with the Maven plugin too.

Yeap, not a problem, I will remove it. Although, and in my humble opinion, I often find myself wanting to quickly deploy a side verticle in order to do some proof of concept.

Sure, verticles are fine for writing trivial small scripts, but the templates are designed for people writing projects which, by definition, are non trivial. If you're just writing a 3 line web server you don't need a build script at all! Just echo <code> > app.js; vertx run app.js

True, it's just a convenience. But now imagine the case where you have multiple vert.x projects. Some are 2.0 and some are of older versions. You obviously cannot have all versions in the same search PATH, so you either have prepared scripts of your own or, you simply start it using maven, which will already have exactly what you need, without having to be switching PATH or including extra external scripts.

4. <configuration/> I think all (?) of these options can go since they're all related to deploying verticles not modules. (With the possible exception of config). Again, I recommend taking a look at the run target in the standard gradle template for how to model this.

I had a look in it, but I will look again in order to see if I'm missing something (I know very litle about Gradle and maybe I need to take some time to go through a good introduction). I did notice that it's only deploying modules. I initially thought this was strange but now I understand why.

 

Test project:

1. Related to above... The test project creates a verticle. We should be pushing modules not verticles.

Yes, It was defaulted to verticle. But I can convert it to modules. Unfortunately, there are issues with the maven harness test lib and maven3 and testing it has become more work than I initially expected. Instead I've provided a simple side example that can be easily adapted to any user needs. It was just an example.

I'm not sure I understand what you mean.

 

2. No tests. One of the big things about the standard templates is they make in-container testing very easy via the new testtools project. We should have examples of in container tests here (integration tests) in the same way as the Gradle template has them.

Yes, Ramki archtype should include the vertx junit annotation.

No please don't. Vert.x junit annotations are deprecated. The new build has a _much_ simpler way to run tests. Take a look at the Gradle build for examples.

Will do. 

Also, the user is free to add the tests it requires. I can add an example. For example, run selenium tests during integration test phase.

Yes please. The purpose of the Maven template project is to provide a template that users can adapt for their own modules. Consequently it's important that we show them how to write tests in different languages. Again, see the Gradle template for examples. You should just be able to copy and paste.

 

3. Not polyglot. The test project should have examples of tests/code written in different languages.

True, as of yet I did not had the time to test it with all available languages.

Just copy and paste from the Gradle project.

Yes, I can reuse the examples provided in the Gradle project. 

[Tim Fox]

On 28/02/13 15:24, froz3n wrote:

Tim,

On Thursday, February 28, 2013 9:26:48 AM UTC-5, Tim Fox wrote:

On 28/02/13 14:14, froz3n wrote:

Template:

1. I'm not sure I understand the different between start and run. Can you clarify?

In maven, in order to build your app you do:

mvn clean install

This will go through all the maven phases ( see here for more info http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)

The start goal starts in daemon mode and ensures that vert.x will not block the maven phase progress.

The run goal is just a super set of start goal that runs in non-daemon mode and is simply used for convenience. Basically, it allows the user to quickly run it's app with the current maven settings without having to run the full maven phases. In this mode, you will have to do a CTRL-C to kill maven/vert.x

I still don't follow. The purpose of a run target is just to run the current module as if you have typed vertx runmod at the command line, but using the dependencies from the build. Why would we need a start target too?

How do you do a CTRL-C when building in a Jenkins or Hudson server?

The purpose of the run task I added in the Gradle template was for a developer to run a local copy of their module so they can play around with it, not so it can be started on Jenkins. Starting/stopping things on CI is probably a nice-to-have but I wouldn't consider it core functionality for developer experience. A good first step would be to get equivalent functionality to what's in the Gradle template working, which should cover 95% of what a dev needs, then we can think about the "extras" later on.

2. stop - is this necessary? Won't CTRL-C do?

When in daemon mode, if you don't use it, then vert.x will keep running until the end of the maven build process.

The purpose of run is to run until you stop it.

Again, CTRL-C is not sufficient.

 

 

3. Verticles - I am _really_ trying to get away from the idea of users deploying apps as straight verticles. This is almost always a bad idea. We should be pushing a standard application setup and that should be a module. I.e. users should always create their apps as modules. Consequently I think all the stuff about packaging/running verticles should be removed from the plugin. (This will also make things a lot simpler!). This is the way the vertx-gradle-template has been designed (it's all about modules), and I think we should be consistent with the Maven plugin too.

Yeap, not a problem, I will remove it. Although, and in my humble opinion, I often find myself wanting to quickly deploy a side verticle in order to do some proof of concept.

Sure, verticles are fine for writing trivial small scripts, but the templates are designed for people writing projects which, by definition, are non trivial. If you're just writing a 3 line web server you don't need a build script at all! Just echo <code> > app.js; vertx run app.js

True, it's just a convenience. But now imagine the case where you have multiple vert.x projects. Some are 2.0 and some are of older versions. You obviously cannot have all versions in the same search PATH, so you either have prepared scripts of your own or, you simply start it using maven, which will already have exactly what you need, without having to be switching PATH or including extra external scripts.

Supporting Vert.x 1.x is not a requirement. No-one will be writing modules in 1.x in a few months time.

[bytor99999]

Supporting Vert.x 1.x is not a requirement. No-one will be writing modules in 1.x in a few months time.

I really hope sooner than that. ;)

We are in ant-scp maven heck trying to deploy our mods to a local mods repository, and it is a pain. Besides a few other features that 2.0 will give us. But our time crunch has not allowed us to go to 2.0 yet without some disruption. Our client people are hounding us to get stuff done so they can test. ;)

Mark 

[ramki]

Hi froz3n,

Its a great start! I took a look at the internals and found that it is way more work than expected.

My comments are inline.

On Thursday, 28 February 2013 04:03:15 UTC+5:30, froz3n wrote:

https://github.com/crazyfrozenpenguin/vertx-maven-plugin

 - Please change the dependencies to io.vertx from org.vertx in the above repo. It doesn't compile and deploy because of this.

https://github.com/crazyfrozenpenguin/vertx-maven-plugin-test

 - Add the sonatype repository in the pom.
 - Again fix the deps to io.vertx from org.vertx.

Sonatype Repo for pom.xml:

    <repositories>
      <repository>
        <id>sonatype</id>
        <url>https://oss.sonatype.org/content/repositories/snapshots</url>
      </repository>
    </repositories>


 

Ramki, please notice that the test is not yet making use of your archtype.

I think it should be me integrating your stuff. From a developer perspective, here is what I think it should be.

$ > mvn archetype:generate  -DarchetypeGroupId=org.vertx.build  -DarchetypeArtifactId=vertx-maven-archetype -DgroupId=com.foo.bar -DartifactId=baz

$ > mvn vertx:start //this will run the sample verticle we have in the gradle-template project myVerticle.

Now, the developer can just go modify the samples we have in any language and take it for a spin. Isn't that the right thing to do?
 

Notice that I have used the assembly plugin to create a zipped module and a uncompressed module in the target directory. The user can then choose which one he would like to use. Also, the target directory is by default the vertx modules directory.

I'm not sure if its a good idea to keep the target directory default to vertx modules directory. I believe any maven user will expect the output to be in target directory. We unnecessarily don't need to educate developers to look for the module in vertx module directory. And while in development we will do countless builds, why should we put something thats being tested and unstable in the default vertx mods directory? From the gradle-template project, there is a copyMod() which will copy to local mods directory. So I guess we should just use that. What do you guys think?

-ramki

[froz3n]

Ramki, let's discuss all this over here (unfortunately I'm not able to reach IRC):

http://chat.stackoverflow.com/rooms/25373/vertx

Although not committed yet, I have added polyglot structure to the vertx-maven-plugin-test project as well as a Selenium test.

Will commit soon.

Reach me so that we can coordinate efforts.

[Tim Fox]

On Friday, 1 March 2013 15:54:33 UTC, ramki wrote:

Hi froz3n,

Its a great start! I took a look at the internals and found that it is way more work than expected.

I'm honestly surprised this appears to be so much more work for Maven, the build is actually pretty simple. Here is the code for the Gradle version https://github.com/vert-x/vertx-gradle-template/blob/master/gradle/vertx.gradle - I'd expect something similar in complexity for Maven.

 

My comments are inline.

On Thursday, 28 February 2013 04:03:15 UTC+5:30, froz3n wrote:

https://github.com/crazyfrozenpenguin/vertx-maven-plugin

 - Please change the dependencies to io.vertx from org.vertx in the above repo. It doesn't compile and deploy because of this.

https://github.com/crazyfrozenpenguin/vertx-maven-plugin-test

 - Add the sonatype repository in the pom.
 - Again fix the deps to io.vertx from org.vertx.

Sonatype Repo for pom.xml:

    <repositories>
      <repository>
        <id>sonatype</id>
        <url>https://oss.sonatype.org/content/repositories/snapshots</url>
      </repository>
    </repositories>


 

Ramki, please notice that the test is not yet making use of your archtype.

I think it should be me integrating your stuff. From a developer perspective, here is what I think it should be.

$ > mvn archetype:generate  -DarchetypeGroupId=org.vertx.build  -DarchetypeArtifactId=vertx-maven-archetype -DgroupId=com.foo.bar -DartifactId=baz

$ > mvn vertx:start //this will run the sample verticle we have in the gradle-template project myVerticle.

Now, the developer can just go modify the samples we have in any language and take it for a spin. Isn't that the right thing to do?
 

Notice that I have used the assembly plugin to create a zipped module and a uncompressed module in the target directory. The user can then choose which one he would like to use. Also, the target directory is by default the vertx modules directory.

I'm not sure if its a good idea to keep the target directory default to vertx modules directory. I believe any maven user will expect the output to be in target directory. We unnecessarily don't need to educate developers to look for the module in vertx module directory. And while in development we will do countless builds, why should we put something thats being tested and unstable in the default vertx mods directory? From the gradle-template project, there is a copyMod() which will copy to local mods directory. So I guess we should just use that. What do you guys think?

The output of the assemble should be a zip file in the normal place - in Gradle this is build/libs, in Maven I believe this should be target/something (?)

During this process the copyMod task will be invoked which places the module in the mods directory where it can be immediately used and picked up on by the tests.

If in doubt, take a look at what the Gradle build does :)

[ramki s]

Sent from my iPhone

On 03-Mar-2013, at 1:27 PM, Tim Fox <timv...@gmail.com> wrote:

On Friday, 1 March 2013 15:54:33 UTC, ramki wrote:

Hi froz3n,

Its a great start! I took a look at the internals and found that it is way more work than expected.

I'm honestly surprised this appears to be so much more work for Maven, the build is actually pretty simple. Here is the code for the Gradle version https://github.com/vert-x/vertx-gradle-template/blob/master/gradle/vertx.gradle - I'd expect something similar in complexity for Maven.

I think it's the power of scriptability in gradle. It was indeed pretty simple in gradle.

The only thing we need to do for maven would be the plugin. Once that's done it will be equally nice to work with maven. I'm sure. 

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/0zpRd-nB1Jg/unsubscribe?hl=en-GB.
To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.

[Bruno Santos]

On Sun, Mar 3, 2013 at 3:32 AM, ramki s <ram...@gmail.com> wrote:
>
>
> Sent from my iPhone
>
> On 03-Mar-2013, at 1:27 PM, Tim Fox <timv...@gmail.com> wrote:
>
>
>
> On Friday, 1 March 2013 15:54:33 UTC, ramki wrote:
>>
>> Hi froz3n,
>>
>> Its a great start! I took a look at the internals and found that it is way
>> more work than expected.
>
>
> I'm honestly surprised this appears to be so much more work for Maven, the
> build is actually pretty simple. Here is the code for the Gradle version
> https://github.com/vert-x/vertx-gradle-template/blob/master/gradle/vertx.gradle
> - I'd expect something similar in complexity for Maven.
>
>
> I think it's the power of scriptability in gradle. It was indeed pretty
> simple in gradle.
>

Yes, I wish It was that easy in Maven to. Unfortunately it is not.
Gradle seems to be a scriptable version of ANT when it comes to define
the different tasks. Unfortunately (or fortunately, depending on the
point of view), Maven is quite rigid and plugins have to comply to
Maven's build phases and structure. Migrating from from ANT to Gradle
seems to be a quite natural process. With Maven though, it is quite
different in the way it works.

> The only thing we need to do for maven would be the plugin. Once that's done
> it will be equally nice to work with maven. I'm sure.

Ramki, are you available on IRC?

--
Bruno Santos
mailto:bmros...@gmail.com

"Treat people as they ought to be, and you will help them
become what they are capable of being." - Goethe

[ramki]

Finally, got the maven archetype completely working including tests, packaging and install. The archetype now auto creates the mods directory before tests and runs the test after that.

I'm thinking this makes the maven archetype 100% complete. Let me know if there is something more to be added or missing.

Froz3n, you might want to take a look at the way the mods directory is created without using the mods-exploded assembler. It is way more easier like this I guess. And looks like we are never able to meet in IRC given the time zones. Let me know if you need help on plugin independently.

Tim,

Few observations from vertx-gradle-template project:

1) Looks like the "SNAPSHOT" is hard wired in the code. If I give my module's version as 1.0.0-SNAPSHOT, it takes it as 1.0.0-SNAPSHOT-SNAPSHOT when trying deploy the module. Any reason behind the hard-wiring? Wouldn't it be ok to just take the module's version and let the developers add SNAPSHOT in their version?

2) When I saw something like deployModule("maven:...), I thought the "maven" part in the string was some kind of an indicator that it needs to be downloaded from maven repositories (remote or local). But it is basically wired in the directory name of the deployed module. If this is the case, do we really need "maven" part in the string? Or is it for future use? Or am I blind? :)

3) Every time I do a clean build, the dependent modules are being downloaded and written to mods directory. Is there a way we can avoid the download everytime?

-ramki

[Tim Fox]

On 04/03/13 16:52, ramki wrote:

Finally, got the maven archetype completely working including tests, packaging and install. The archetype now auto creates the mods directory before tests and runs the test after that.

I'm thinking this makes the maven archetype 100% complete. Let me know if there is something more to be added or missing.

Froz3n, you might want to take a look at the way the mods directory is created without using the mods-exploded assembler. It is way more easier like this I guess. And looks like we are never able to meet in IRC given the time zones. Let me know if you need help on plugin independently.

Tim,

Few observations from vertx-gradle-template project:

1) Looks like the "SNAPSHOT" is hard wired in the code. If I give my module's version as 1.0.0-SNAPSHOT, it takes it as 1.0.0-SNAPSHOT-SNAPSHOT when trying deploy the module.

I can't replicate this. With the current vertx-gradle-template in github, the module name is 1.0.0-SNAPSHOT, and it doesn't try and deploy it as 1.0.0-SNAPSHOT-SNAPSHOT when running the tests. This is evidenced by the current CI passing. Or perhaps I am misunderstanding what you mean?

Any reason behind the hard-wiring? Wouldn't it be ok to just take the module's version and let the developers add SNAPSHOT in their version?

2) When I saw something like deployModule("maven:...), I thought the "maven" part in the string was some kind of an indicator that it needs to be downloaded from maven repositories (remote or local). But it is basically wired in the directory name of the deployed module. If this is the case, do we really need "maven" part in the string? Or is it for future use? Or am I blind? :)

A module name starts with a prefix. The current valid values are "maven", "bintray", and "old". It represents where your module is destined to go. The assumption is that Maven users will probably upload (and download) their modules to Maven since that's what they're used to.

Without the prefix, Vert.x wouldn't know where to look when downloading modules either. (Vert.x can look in maven local, maven remote, bintray and the old Vert.x 1.x repo)

3) Every time I do a clean build, the dependent modules are being downloaded and written to mods directory. Is there a way we can avoid the download everytime?

Don't do a clean ;)

Clean is doing what it should do.. clean up the local state, and that includes any modules locally installed.

You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

[froz3n]

Ramki,

Eventually we'll be able to chat... one day! :)

Anyway, the latest release of the plugin and test project are now available. Code has been simplified and it is pretty stable.

You'll notice that I've added a sample polyglot structure. The example will deploy a Javascript based module. On the top of it, a sample selenium test as also been added.

Obviously all this is open for discussion, whenever we actually get to talk.

Tim, I know that the verticles are still deployable and I'm yet to remove it it's options from the maven plugin (will do that soon).

[froz3n]

In addition, coffee and python modules were not working last time I checked. All others should be good to go. Scala was consciously not added (as per Tim request).

[froz3n]

Also, just fixed the vert.x artifact name from org.vertx to io.vertx. Somehow I was under the impression that for 2.0 Vert.x was moving to org.vertx. 

Tim, is vertx sticking with io?

[froz3n]

Ramki,

Somehow I've missed this message. I will have a look in your points later today. I honestly didn't have the time yet to try the new archtype.

Also, please have a look in the test example and let me know how you are thinking of adding the polyglot structure to the archtype. Are we providing a specific structure for a given language or are we providing a single structure that includes an example for all languages and the user is then responsible for tailoring it to his need?

later,

On Monday, March 4, 2013 11:52:20 AM UTC-5, ramki wrote:

[Richard Vowles]

On Tuesday, March 5, 2013 6:13:06 AM UTC+13, Tim Fox wrote:

A module name starts with a prefix. The current valid values are "maven", "bintray", and "old". It represents where your module is destined to go. The assumption is that Maven users will probably upload (and download) their modules to Maven since that's what they're used to.

Without the prefix, Vert.x wouldn't know where to look when downloading modules either. (Vert.x can look in maven local, maven remote, bintray and the old Vert.x 1.x repo)

With Maven - VertX itself should never be downloading modules, it should let Maven do that. I'm struggling with this part of VertX and it is a show stopper to us adopting us - this packaging stuff. I need our devs to be able to have their IDE open, their main VertX project open with any number of mods also open and Maven being able to recognize them locally in their respective directories (as both Eclipse and IDEA do), tie them together on run (without the need to package them up - they should just run unexploded, auto picking up the dependency tree required for the mod from the mod's pom and the exploded classes from the class directory of the project). As class files change, they should be able to be reloaded by JRebel. Once we decide to package them up, it should run entirely from inside a runnable jar file (like a runnable war file does already) - it should never ever download anything, you should just be able to type "java -jar website.jar" - pass some system properties and have it run. VertX should never download anything or expect any individual mod to be in any individual directory - I need to be able to just pass it a fully realized classpath for each verticle and it needs to accept that.

Without these capabilities - things we have struggled extremely hard to try and get in Grails, VertX is just another proprietary bundling technology that is anti-productive in a Java/Groovy world and we simply won't be able to justify moving to it. 

Thinking about it now, it seems to me to be more like a slightly less complex but just as "different" OSGI stack. *sigh*

Any suggestions on how/if we can do something about this I'd love to hear. The concepts and technology in the VertX stack are very desirable, the packaging is just a real sticking point. 

[Tim Fox]

On 05/03/13 08:45, Richard Vowles wrote:

On Tuesday, March 5, 2013 6:13:06 AM UTC+13, Tim Fox wrote:

A module name starts with a prefix. The current valid values are "maven", "bintray", and "old". It represents where your module is destined to go. The assumption is that Maven users will probably upload (and download) their modules to Maven since that's what they're used to.

Without the prefix, Vert.x wouldn't know where to look when downloading modules either. (Vert.x can look in maven local, maven remote, bintray and the old Vert.x 1.x repo)

With Maven - VertX itself should never be downloading modules, it should let Maven do that. I'm struggling with this part of VertX and it is a show stopper to us adopting us - this packaging stuff. I need our devs to be able to have their IDE open, their main VertX project open with any number of mods also open and Maven being able to recognize them locally in their respective directories (as both Eclipse and IDEA do),

This works as you describe when using the Standard Gradle template - I can seamlessly run, test and debug into Vert.x modules without having to rebuild anything when the code changes. The Maven template should be done before too long and will allow you to do exactly the same thing.

[Tim Fox]

On 05/03/13 08:45, Richard Vowles wrote:

On Tuesday, March 5, 2013 6:13:06 AM UTC+13, Tim Fox wrote:

A module name starts with a prefix. The current valid values are "maven", "bintray", and "old". It represents where your module is destined to go. The assumption is that Maven users will probably upload (and download) their modules to Maven since that's what they're used to.

Without the prefix, Vert.x wouldn't know where to look when downloading modules either. (Vert.x can look in maven local, maven remote, bintray and the old Vert.x 1.x repo)

With Maven - VertX itself should never be downloading modules, it should let Maven do that. I'm struggling with this part of VertX and it is a show stopper to us adopting us - this packaging stuff. I need our devs to be able to have their IDE open, their main VertX project open with any number of mods also open and Maven being able to recognize them locally in their respective directories (as both Eclipse and IDEA do), tie them together on run (without the need to package them up - they should just run unexploded, auto picking up the dependency tree required for the mod from the mod's pom and the exploded classes from the class directory of the project). As class files change, they should be able to be reloaded by JRebel. Once we decide to package them up, it should run entirely from inside a runnable jar file (like a runnable war file does already) - it should never ever download anything, you should just be able to type "java -jar website.jar" - pass some system properties and have it run.

That's already supported in Vert.x 2.0

[Richard Vowles]

Are you talking about something other than the linked vertx gradle template linked to in the included posting? Because that appears to copy the mods into your directory and run then from there. It won't detect any changes in the original project, or any dependency updates. Also, is this vertx 2 (which is not out yet?)

Is there something else I can look at? I have already re-written the standard Maven plugin for Vertx so it works in an expected fashion for Maven, if the API provides some mechanism to just hand it a classloader and a module name and have it NOT try and get files from anywhere else, that will probably largely solve the problem. 

On Tuesday, March 5, 2013 10:33:35 PM UTC+13, Tim Fox wrote:

This works as you describe when using the Standard Gradle template - I can seamlessly run, test and debug into Vert.x modules without having to rebuild anything when the code changes. The Maven template should be done before too long and will allow you to do exactly the same thing.

[Tim Fox]

Ramki-

I've take a look at your archetype - it certainly looks like progress has been made :)

Some comments:

assembly/mod.xml:

* Everything from src/main/resources should be included in jar, not just mod.json (Isn't that the default anyway?)

* src/test/resources should not be included

Tests:

* GroovyIntegrationTests/JavaScriptIntegrationTests/PythonIntegrationTests/RubyIntegrationTests - the regexp seems to have been munged, e.g. 'filenameFilter=".+${symbol_escape}${symbol_escape}.groovy"

This probably explains why only the JavaIntegrationTest is being run when I execute mvn test?

* Test report - I can't see any html test report produced after running mvn test. Can we have something similar to what the Gradle build produces?

* A system property should be used (vertx.moduleName) when deploying modules - this means the user doesn't have to hardcoded the module name in there which would make tests brittle like this:

container.deployModule("maven:org.myorg:my-project:1.0-SNAPSHOT")

* clean target doesn't delete the mods directory

* The mod zip file produced has the wrong structure - it contains a mods/mod-name directory - this should not be there.

* Where is the target to run the module? (i.e. equivalent of runMod target in Gradle build)

* A lot of what is in pom.xml is just boilerplate - is it possible to separate this out into a separate file since it won't change - I'd rather see an approach like that (as we did in the Gradle template)

* GroupId, module-directory and mods-directory seem to have the group id duplicated:

<groupId>io.vertx</groupId>

<module-directory>io.vertx.my-project-v1.0</module-directory>

<mods-directory>maven:io.vertx:my-project:1.0-SNAPSHOT</mods-directory>

* Typo <id>sonatypet</id>

should be sonatype - Have you tried pushing to sonatype?

* Pull in deps target is missing

[Richard Vowles]

The platform manager code from what looks like VertX 2 has

void deployVerticle(String main,
                      JsonObject config, URL[] classpath,
                      int instances,
                      String includes,
                      Handler<String> doneHandler);

and

 void deployWorkerVerticle(boolean multiThreaded, String main,
                            JsonObject config, URL[] classpath,
                            int instances,
                            String includes,
                            Handler<String> doneHandler);

exposed - this looks like it would do it?

[Tim Fox]

On 05/03/13 09:47, Richard Vowles wrote:

Are you talking about something other than the linked vertx gradle template linked to in the included posting? Because that appears to copy the mods into your directory and run then from there. It won't detect any changes in the original project, or any dependency updates.

It does detect changes in the original project, since in Vert.x 2.0 resources can be loaded from the system classpath, which in the IDE will be setup to include all the resources of the application.

Also, is this vertx 2 (which is not out yet?)

Yes, all of this is Vert.x 2.0. A major thrust of Vert.x 2.0 is to make developer experience a lot easier. This includes seamless build/test/run/debug.

Is there something else I can look at? I have already re-written the standard Maven plugin for Vertx so it works in an expected fashion for Maven, if the API provides some mechanism to just hand it a classloader and a module name and have it NOT try and get files from anywhere else, that will probably largely solve the problem. 

On Tuesday, March 5, 2013 10:33:35 PM UTC+13, Tim Fox wrote:

This works as you describe when using the Standard Gradle template - I can seamlessly run, test and debug into Vert.x modules without having to rebuild anything when the code changes. The Maven template should be done before too long and will allow you to do exactly the same thing.

> I'm honestly surprised this appears to be so much more work for Maven, the
> build is actually pretty simple. Here is the code for the Gradle version
> https://github.com/vert-x/vertx-gradle-template/blob/master/gradle/vertx.gradle
> - I'd expect something similar in complexity for Maven.
>

[Richard Vowles]

On Tuesday, March 5, 2013 10:52:53 PM UTC+13, Tim Fox wrote:

On 05/03/13 09:47, Richard Vowles wrote:

Are you talking about something other than the linked vertx gradle template linked to in the included posting? Because that appears to copy the mods into your directory and run then from there. It won't detect any changes in the original project, or any dependency updates.

It does detect changes in the original project, since in Vert.x 2.0 resources can be loaded from the system classpath, which in the IDE will be setup to include all the resources of the application.

So each verticle now gets a copy of the system classpath? Doesn't that mean ensuring de-duping of dependencies which was possible before is now critical? You can't have different mods wanting different versions? I'm all for that! That makes it *considerably* easier if you are planning on having a single classpath across the entire app. I intend to add a Maven packaging type <packaging>vertx-mod</packaging> so the build can auto-deploy the mods it recognizes - with a single classpath that makes that all much, much easier.

 

Also, is this vertx 2 (which is not out yet?)

Yes, all of this is Vert.x 2.0. A major thrust of Vert.x 2.0 is to make developer experience a lot easier. This includes seamless build/test/run/debug.

And this is only in the sonatype repos as a snapshot or is it best to run/deploy locally into our Nexus from Github? 

[Tim Fox]

Hi froz3n,

I've taken a look at the latest stuff here https://github.com/crazyfrozenpenguin/vertx-maven-plugin-test.git

To be honest, I'm not sure where to begin. It doesn't seem to have any resemblance to the structure of the example Gradle project (they should be almost identical). I can't see the new test framework being used.

I also don't understand the relation between vertx-maven-plugin and vertx-maven-plugin-test. Can you walk me through this? I also don't understand why all the code about starting servers is necessary - this should just be one-liner using the PlatformManager as the Gradle task does.

I guess I'm missing something? Or I'm looking in the wrong place maybe?

You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

[froz3n]

Tim

On Tuesday, March 5, 2013 5:07:07 AM UTC-5, Tim Fox wrote:

Hi froz3n,

I've taken a look at the latest stuff here https://github.com/crazyfrozenpenguin/vertx-maven-plugin-test.git

To be honest, I'm not sure where to begin. It doesn't seem to have any resemblance to the structure of the example Gradle project (they should be almost identical). I can't see the new test framework being used.

Keep in mind that this is not based on archtype to be used (not yet anyway). This is just something that I have put together to simply test the plugin being developed.

 

I also don't understand the relation between vertx-maven-plugin and vertx-maven-plugin-test. Can you walk me through this? I also don't understand why all the code about starting servers is necessary - this should just be one-liner using the PlatformManager as the Gradle task does.

I guess I'm missing something? Or I'm looking in the wrong place maybe?

Yes, I think you're missing how maven really works. Maven works in a much different way than Gradle. They are not apples-to-apples. Gradle, very much like ANT, uses the concepts of tasks and tasks dependencies in order to allow developers to create a desired build setup. In addition, Gradle is scriptable and Maven is not. In Maven tasks do not exist. What exists is a Maven lifecycle that goes through pre-defined phases during the build process. To these phases you can hook plugins that implement goals. So, for all effects, the closest thing you have to a task in Gradle or ANT is a plugin goal. 

Also, let me explain how to work with the provided test. There two ways to work with it and they are both required.

Both examples assume that you compiled the vertx-maven-plugin and that it available in your local maven repo. If you have not, please check the code out from github (https://github.com/crazyfrozenpenguin/vertx-maven-plugin) and, from the created directory do" "mvn clean install".

Example 1: Running the full maven lifecycle

This working mode is useful for creating a release, source delivery or simply for running it in a CI environment since it will basically execute all phases from the maven lifecycle (compile, test, etc). 

open a terminal/command window and navigate into the vertx-maven-plugin-test directory.

Do: "mvn clean install". 

During the process you will notice maven going through the several phases and calling the respective plugin goals. At the "pre-inegration-test" phase two plugins will be executed. One is the Selenium server plugin that will start the Selenium server and the other is the Vert.x server that will start the vert.x server and deploy the module in development. Notice that Vert.x will not block and wait for a CTRL-C. This is because doing so would stop the maven lifecycle from proceeding. Hence, the during the next phase, the "integration-test" phase, the integration tests are executed and you should notice a Firefox window come up and execute a selenium test. After that the "post-integration-test" is executed and so on...

Example 2: Development mode

This working mode is useful for development.

 

open two terminal/command windows and navigate into the vertx-maven-plugin-test directory.

In one terminal you do: "mvn selenium:start-server -Dport=8888". 

In the other terminal you do: "mvn vertx:run"

Notice that both the Selenium server and vertx server are now blocking and waiting for a CTRL-C to stop it.

In eclipse, import the vertx-maven-plugin-test directory as a maven project into your eclipse workspace (you'll need m2e plugin for eclipse installed. If you are using something like Spring STS or JBoss Dev Studio, then you should be good to go). In eclipse, open the selenium test class (CTRL - SHIFT - t) named VertxTest and put a debug point anywhere in the code. Then just run the test as a JUnit test.

This pretty much covers most development and CI needs. But Richard does raise some good points, specially when it comes to have the module hot deployed on source code changes.

[Tim Fox]

On 05/03/13 14:16, froz3n wrote:

Tim

On Tuesday, March 5, 2013 5:07:07 AM UTC-5, Tim Fox wrote:

Hi froz3n,

I've taken a look at the latest stuff here https://github.com/crazyfrozenpenguin/vertx-maven-plugin-test.git

To be honest, I'm not sure where to begin. It doesn't seem to have any resemblance to the structure of the example Gradle project (they should be almost identical). I can't see the new test framework being used.

Keep in mind that this is not based on archtype to be used (not yet anyway). This is just something that I have put together to simply test the plugin being developed.

 

I also don't understand the relation between vertx-maven-plugin and vertx-maven-plugin-test. Can you walk me through this? I also don't understand why all the code about starting servers is necessary - this should just be one-liner using the PlatformManager as the Gradle task does.

I guess I'm missing something? Or I'm looking in the wrong place maybe?

Yes, I think you're missing how maven really works. Maven works in a much different way than Gradle.

I'm referring to the project structure - it's completely different in your template.

I've used a standard Maven project structure in the Gradle template, so there's no reason why they can't be followed. I notice Ramki's archectype does mirror the Gradle template closely.

They are not apples-to-apples. Gradle, very much like ANT, uses the concepts of tasks and tasks dependencies in order to allow developers to create a desired build setup. In addition, Gradle is scriptable and Maven is not. In Maven tasks do not exist. What exists is a Maven lifecycle that goes through pre-defined phases during the build process. To these phases you can hook plugins that implement goals. So, for all effects, the closest thing you have to a task in Gradle or ANT is a plugin goal.

Also, let me explain how to work with the provided test. There two ways to work with it and they are both required.

Both examples assume that you compiled the vertx-maven-plugin and that it available in your local maven repo. If you have not, please check the code out from github (https://github.com/crazyfrozenpenguin/vertx-maven-plugin) and, from the created directory do" "mvn clean install".

Example 1: Running the full maven lifecycle

This working mode is useful for creating a release, source delivery or simply for running it in a CI environment since it will basically execute all phases from the maven lifecycle (compile, test, etc). 

open a terminal/command window and navigate into the vertx-maven-plugin-test directory.

Do: "mvn clean install". 

During the process you will notice maven going through the several phases and calling the respective plugin goals. At the "pre-inegration-test" phase two plugins will be executed. One is the Selenium server plugin that will start the Selenium server and the other is the Vert.x server that will start the vert.x server and deploy the module in development. Notice that Vert.x will not block and wait for a CTRL-C. This is because doing so would stop the maven lifecycle from proceeding. Hence, the during the next phase, the "integration-test" phase, the integration tests are executed and you should notice a Firefox window come up and execute a selenium test. After that the "post-integration-test" is executed and so on...

No, no, no. We already have a way of running Vert.x tests in the container (the Gradle template and Ramki's archetype uses it). If Maven can run Junit tests then it will be able to run them. You don't need any special starting up of servers in order to do this. The in container test framework has also been designed so tests will run seamlessly in IDEs without any special setup. Also debugging is supported. Please use that.

Example 2: Development mode

This working mode is useful for development.

 

open two terminal/command windows and navigate into the vertx-maven-plugin-test directory.

In one terminal you do: "mvn selenium:start-server -Dport=8888". 

In the other terminal you do: "mvn vertx:run"

Notice that both the Selenium server and vertx server are now blocking and waiting for a CTRL-C to stop it.

In eclipse, import the vertx-maven-plugin-test directory as a maven project into your eclipse workspace (you'll need m2e plugin for eclipse installed. If you are using something like Spring STS or JBoss Dev Studio, then you should be good to go). In eclipse, open the selenium test class (CTRL - SHIFT - t) named VertxTest and put a debug point anywhere in the code. Then just run the test as a JUnit test.

I don't even know what Selenium is but have no idea how it's relevant to a standard build template for Vert.x!

[froz3n]

On Tuesday, March 5, 2013 9:38:09 AM UTC-5, Tim Fox wrote:

On 05/03/13 14:16, froz3n wrote:

Tim

On Tuesday, March 5, 2013 5:07:07 AM UTC-5, Tim Fox wrote:

Hi froz3n,

I've taken a look at the latest stuff here https://github.com/crazyfrozenpenguin/vertx-maven-plugin-test.git

To be honest, I'm not sure where to begin. It doesn't seem to have any resemblance to the structure of the example Gradle project (they should be almost identical). I can't see the new test framework being used.

Keep in mind that this is not based on archtype to be used (not yet anyway). This is just something that I have put together to simply test the plugin being developed.

 

I also don't understand the relation between vertx-maven-plugin and vertx-maven-plugin-test. Can you walk me through this? I also don't understand why all the code about starting servers is necessary - this should just be one-liner using the PlatformManager as the Gradle task does.

I guess I'm missing something? Or I'm looking in the wrong place maybe?

Yes, I think you're missing how maven really works. Maven works in a much different way than Gradle.

I'm referring to the project structure - it's completely different in your template.

That's correct, That archtype is in development and there are things that are different. The structure does follow the maven way of organizing src and test directories. Unfortunatly, maven only allows for one source directory and one test directory. Extra source directories will have to be added as resources. So, and as I recall, if you want to have a src/main/java and a src/main/groovy one of them will have to added as a resource directory.

 

I've used a standard Maven project structure in the Gradle template, so there's no reason why they can't be followed. I notice Ramki's archectype does mirror the Gradle template closely.

Yes, and when we are done, this test will be implemented from a specialization of the archtype that Ramki is working on.

 

They are not apples-to-apples. Gradle, very much like ANT, uses the concepts of tasks and tasks dependencies in order to allow developers to create a desired build setup. In addition, Gradle is scriptable and Maven is not. In Maven tasks do not exist. What exists is a Maven lifecycle that goes through pre-defined phases during the build process. To these phases you can hook plugins that implement goals. So, for all effects, the closest thing you have to a task in Gradle or ANT is a plugin goal.

Also, let me explain how to work with the provided test. There two ways to work with it and they are both required.

Both examples assume that you compiled the vertx-maven-plugin and that it available in your local maven repo. If you have not, please check the code out from github (https://github.com/crazyfrozenpenguin/vertx-maven-plugin) and, from the created directory do" "mvn clean install".

Example 1: Running the full maven lifecycle

This working mode is useful for creating a release, source delivery or simply for running it in a CI environment since it will basically execute all phases from the maven lifecycle (compile, test, etc). 

open a terminal/command window and navigate into the vertx-maven-plugin-test directory.

Do: "mvn clean install". 

During the process you will notice maven going through the several phases and calling the respective plugin goals. At the "pre-inegration-test" phase two plugins will be executed. One is the Selenium server plugin that will start the Selenium server and the other is the Vert.x server that will start the vert.x server and deploy the module in development. Notice that Vert.x will not block and wait for a CTRL-C. This is because doing so would stop the maven lifecycle from proceeding. Hence, the during the next phase, the "integration-test" phase, the integration tests are executed and you should notice a Firefox window come up and execute a selenium test. After that the "post-integration-test" is executed and so on...

No, no, no. We already have a way of running Vert.x tests in the container (the Gradle template and Ramki's archetype uses it). If Maven can run Junit tests then it will be able to run them. You don't need any special starting up of servers in order to do this. The in container test framework has also been designed so tests will run seamlessly in IDEs without any special setup. Also debugging is supported. Please use that.

This is different. Vert.x now offeres in-container tests (similar concept to what archillian is to jboss). Still, in some cases, you still want to hit the server from the outside. That's the sample test I've provided.

Example 2: Development mode

This working mode is useful for development.

 

open two terminal/command windows and navigate into the vertx-maven-plugin-test directory.

In one terminal you do: "mvn selenium:start-server -Dport=8888". 

In the other terminal you do: "mvn vertx:run"

Notice that both the Selenium server and vertx server are now blocking and waiting for a CTRL-C to stop it.

In eclipse, import the vertx-maven-plugin-test directory as a maven project into your eclipse workspace (you'll need m2e plugin for eclipse installed. If you are using something like Spring STS or JBoss Dev Studio, then you should be good to go). In eclipse, open the selenium test class (CTRL - SHIFT - t) named VertxTest and put a debug point anywhere in the code. Then just run the test as a JUnit test.

I don't even know what Selenium is but have no idea how it's relevant to a standard build template for Vert.x!

Selenium is a web test framework that allows you to automate web page tests. It is not relevant to the standard build of Vert.x and that's why I did not provide it initially. But you did ask me to include it in one of our previous discussions. So I did!

[Tim Fox]

On 05/03/13 14:54, froz3n wrote:

On Tuesday, March 5, 2013 9:38:09 AM UTC-5, Tim Fox wrote:

On 05/03/13 14:16, froz3n wrote:

Tim

On Tuesday, March 5, 2013 5:07:07 AM UTC-5, Tim Fox wrote:

Hi froz3n,

I've taken a look at the latest stuff here https://github.com/crazyfrozenpenguin/vertx-maven-plugin-test.git

To be honest, I'm not sure where to begin. It doesn't seem to have any resemblance to the structure of the example Gradle project (they should be almost identical). I can't see the new test framework being used.

Keep in mind that this is not based on archtype to be used (not yet anyway). This is just something that I have put together to simply test the plugin being developed.

 

I also don't understand the relation between vertx-maven-plugin and vertx-maven-plugin-test. Can you walk me through this? I also don't understand why all the code about starting servers is necessary - this should just be one-liner using the PlatformManager as the Gradle task does.

I guess I'm missing something? Or I'm looking in the wrong place maybe?

Yes, I think you're missing how maven really works. Maven works in a much different way than Gradle.

I'm referring to the project structure - it's completely different in your template.

That's correct, That archtype is in development and there are things that are different. The structure does follow the maven way of organizing src and test directories. Unfortunatly, maven only allows for one source directory and one test directory.

You only need one source and test dir. I think Ramki has got it right in his archetype.

Extra source directories will have to be added as resources. So, and as I recall, if you want to have a src/main/java and a src/main/groovy one of them will have to added as a resource directory.

 

I've used a standard Maven project structure in the Gradle template, so there's no reason why they can't be followed. I notice Ramki's archectype does mirror the Gradle template closely.

Yes, and when we are done, this test will be implemented from a specialization of the archtype that Ramki is working on.

 

They are not apples-to-apples. Gradle, very much like ANT, uses the concepts of tasks and tasks dependencies in order to allow developers to create a desired build setup. In addition, Gradle is scriptable and Maven is not. In Maven tasks do not exist. What exists is a Maven lifecycle that goes through pre-defined phases during the build process. To these phases you can hook plugins that implement goals. So, for all effects, the closest thing you have to a task in Gradle or ANT is a plugin goal.

Also, let me explain how to work with the provided test. There two ways to work with it and they are both required.

Both examples assume that you compiled the vertx-maven-plugin and that it available in your local maven repo. If you have not, please check the code out from github (https://github.com/crazyfrozenpenguin/vertx-maven-plugin) and, from the created directory do" "mvn clean install".

Example 1: Running the full maven lifecycle

This working mode is useful for creating a release, source delivery or simply for running it in a CI environment since it will basically execute all phases from the maven lifecycle (compile, test, etc). 

open a terminal/command window and navigate into the vertx-maven-plugin-test directory.

Do: "mvn clean install". 

During the process you will notice maven going through the several phases and calling the respective plugin goals. At the "pre-inegration-test" phase two plugins will be executed. One is the Selenium server plugin that will start the Selenium server and the other is the Vert.x server that will start the vert.x server and deploy the module in development. Notice that Vert.x will not block and wait for a CTRL-C. This is because doing so would stop the maven lifecycle from proceeding. Hence, the during the next phase, the "integration-test" phase, the integration tests are executed and you should notice a Firefox window come up and execute a selenium test. After that the "post-integration-test" is executed and so on...

No, no, no. We already have a way of running Vert.x tests in the container (the Gradle template and Ramki's archetype uses it). If Maven can run Junit tests then it will be able to run them. You don't need any special starting up of servers in order to do this. The in container test framework has also been designed so tests will run seamlessly in IDEs without any special setup. Also debugging is supported. Please use that.

This is different. Vert.x now offeres in-container tests (similar concept to what archillian is to jboss). Still, in some cases, you still want to hit the server from the outside. That's the sample test I've provided.

I think the key thing to do is to get the template demonstrating how to run unit and integration tests. I can't see either of those in your template currently. Other types of test can come later.

[froz3n]

Yes, that's what will be like in the end.

[Tim Fox]

Great :)

It's entirely up to you of course, but, since Ramki seems to be a bit further along the path, what I would suggest at this point is perhaps you could join forces with Ramki and work on his version. I think he has basically the vertx:run and pullinDeps "tasks" to complete.

[ramki]

Status inline.

On Tuesday, 5 March 2013 15:17:18 UTC+5:30, Tim Fox wrote:

assembly/mod.xml:

* Everything from src/main/resources should be included in jar, not just mod.json (Isn't that the default anyway?)

Done.
 

* src/test/resources should not be included

Done.
 

Tests:

* GroovyIntegrationTests/JavaScriptIntegrationTests/PythonIntegrationTests/RubyIntegrationTests - the regexp seems to have been munged, e.g. 'filenameFilter=".+${symbol_escape}${symbol_escape}.groovy"

This probably explains why only the JavaIntegrationTest is being run when I execute mvn test?

* Test report - I can't see any html test report produced after running mvn test. Can we have something similar to what the Gradle build produces?

* A system property should be used (vertx.moduleName) when deploying modules - this means the user doesn't have to hardcoded the module name in there which would make tests brittle like this:

container.deployModule("maven:org.myorg:my-project:1.0-SNAPSHOT")

* clean target doesn't delete the mods directory

Done.
 

* The mod zip file produced has the wrong structure - it contains a mods/mod-name directory - this should not be there.

Done.

* Where is the target to run the module? (i.e. equivalent of runMod target in Gradle build)

* A lot of what is in pom.xml is just boilerplate - is it possible to separate this out into a separate file since it won't change - I'd rather see an approach like that (as we did in the Gradle template)

* GroupId, module-directory and mods-directory seem to have the group id duplicated:

<groupId>io.vertx</groupId>

<module-directory>io.vertx.my-project-v1.0</module-directory>

<mods-directory>maven:io.vertx:my-project:1.0-SNAPSHOT</mods-directory>

Done.

* Typo <id>sonatypet</id>

 

should be sonatype - Have you tried pushing to sonatype?

Done.
 

* Pull in deps target is missing

Working on other stuff.

-ramki

[Richard Vowles]

On Wednesday, March 6, 2013 4:11:34 AM UTC+13, Tim Fox wrote:

 

You only need one source and test dir. I think Ramki has got it right in his archetype.

No you don't - you want as many as there are sources and test directories. 

Yes, and when we are done, this test will be implemented from a specialization of the archtype that Ramki is working on.

I think the key thing to do is to get the template demonstrating how to run unit and integration tests. I can't see either of those in your template currently. Other types of test can come later.

These should just be the surefire and failsafe plugins, they shouldn't be included in an archetype in the end anyway, they should always be in the (functional only) parent and anyone using Maven should know how to do. What froz3n is setting up is functional tests which require more thought.

I don't even know what Selenium is but have no idea how it's relevant to a standard build template for Vert.x!

Selenium is a web test framework that allows you to automate web page tests. It is not relevant to the standard build of Vert.x and that's why I did not provide it initially. But you did ask me to include it in one of our previous discussions. So I did!

I am almost stunned to disbelief by this comment! 

This pretty much covers most development and CI needs. But Richard does raise some good points, specially when it comes to have the module hot deployed on source code changes.

Yes, the Maven plugin must *never* copy mods into the local directory. It completely breaks the developer process and if that PlatformLocator API only uses copied mods, it shouldn't be used. mods should be identified as such in the POM and treated accordingly at startup instead. There is no reason why the Maven plugin can't just easily identify all vertx mods by their packaging and auto-deploy them in  the case of integration and functional testing.

Richard 

[Tim Fox]

On Tuesday, 5 March 2013 22:38:25 UTC, Richard Vowles wrote:

On Wednesday, March 6, 2013 4:11:34 AM UTC+13, Tim Fox wrote:

 

You only need one source and test dir. I think Ramki has got it right in his archetype.

No you don't - you want as many as there are sources and test directories. 

Yes, and when we are done, this test will be implemented from a specialization of the archtype that Ramki is working on.

I think the key thing to do is to get the template demonstrating how to run unit and integration tests. I can't see either of those in your template currently. Other types of test can come later.

These should just be the surefire and failsafe plugins, they shouldn't be included in an archetype in the end anyway,

Honestly I don't care whether are archetype is used or not.

All I am looking for here is an example template Maven Vert.x project that devs can look at and see: ah that's how I run an incontainer test, that's where my mod goes, etc, so they can get up and running quickly without having to do the heavy lifting themselves.

I'm honestly very surprised how difficult this has proven with Maven compared to Gradle, and anyone how knows me knows I am _not_ a Gradle fan. 1-0 to Gradle so far....