Use a maven classifier when resolving modules?

[johnp...@gmail.com]

I don't consider myself a maven fanatic, but I find it awkard the way CR1 forces the vertx module (.zip) as the primary artifact for a project. Maven projects do not allow a packaging type of zip. This seems like a perfect candidate for using a classifier on the vertx module artifact. The vertx module would be a secondary artifact similar to sources and javadoc, and the project could be packaged as a jar or pom as desired.

The source change in vertx-platform is rather trivial, though the maven archtype and the gradle scripts for each module needs to updated as well.

I've tested the resolution change locally with success, but this requires a large number of module changes so I'd like to see if there are any objections to using a classifier during maven resolution?

-------

As this is my first post here, I want to thank Tim Fox and other contributors for all their hard work. 2.0 is a major improvement over 1.3.1 and I am very excited to see this running in our production enviroment with the new netty framework.

[ramki s]

Can you elaborate a bit more on classifier?

The module packaging we have in vert.x is kind of unique given to its polyglot nature. We use maven to build the modules the way module has been designed instead of other way around. 

-ramki

--
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.
 
 

[johnp...@gmail.com]

There is no reason to change the contents of the zip file, only the URI used to download it in MavenResolution.java

Take for instance the mod-web-server and a classifier of mod. The contents of the directory for the project in maven central would be http://repo2.maven.org/maven2/io/vertx/mod-web-server/2.0.0-CR1/

mod-web-server-2.0.0-CR1-javadoc.jar               14-Jun-2013 15:19               42166
mod-web-server-2.0.0-CR1-javadoc.jar.asc           14-Jun-2013 15:19                 475
mod-web-server-2.0.0-CR1-javadoc.jar.asc.md5       14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1-javadoc.jar.asc.sha1      14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1-javadoc.jar.md5           14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1-javadoc.jar.sha1          14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1-sources.jar               14-Jun-2013 15:19                5881
mod-web-server-2.0.0-CR1-sources.jar.asc           14-Jun-2013 15:19                 475
mod-web-server-2.0.0-CR1-sources.jar.asc.md5       14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1-sources.jar.asc.sha1      14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1-sources.jar.md5           14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1-sources.jar.sha1          14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1.jar                       14-Jun-2013 15:19                8813
mod-web-server-2.0.0-CR1.jar.asc                   14-Jun-2013 15:19                 475
mod-web-server-2.0.0-CR1.jar.asc.md5               14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1.jar.asc.sha1              14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1.jar.md5                   14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1.jar.sha1                  14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1.pom                       14-Jun-2013 15:19                1465
mod-web-server-2.0.0-CR1.pom.asc                   14-Jun-2013 15:19                 475
mod-web-server-2.0.0-CR1.pom.asc.md5               14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1.pom.asc.sha1              14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1.pom.md5                   14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1.pom.sha1                  14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1-mod.zip                   14-Jun-2013 15:19                8574
mod-web-server-2.0.0-CR1-mod.zip.asc               14-Jun-2013 15:19                 475
mod-web-server-2.0.0-CR1-mod.zip.asc.md5           14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1-mod.zip.asc.sha1          14-Jun-2013 15:19                  40
mod-web-server-2.0.0-CR1-mod.zip.md5               14-Jun-2013 15:19                  32
mod-web-server-2.0.0-CR1-mod.zip.sha1              14-Jun-2013 15:19                  40

A maven classifier is an optional 5th element of an artifact name. The maven view of things is that the project's output is still a jar, and if we want attach a secondary artifact of zip, we can do that using the classifier mechanism. Having a zip file with the same "name" as the jar interferes with server indexing and possibly building more complex projects.

Furthermore, the CR1 archtype fails on recent versions of maven because it "exploits" a maven assembly bug which allows an empty or missing assemblyId. Setting the assemblyId in /src/main/assembly/mod.xml to mod would fix this.

http://jira.codehaus.org/browse/MASSEMBLY-464

http://jira.codehaus.org/browse/MASSEMBLY-517

[Tim Fox]

John,

Can you elaborate a bit? I'm not quite sure what you're suggesting here.

[Tim Fox]

For Vert.x modules, the main artifact is a .zip, and there might
(optionally) be a .jar there too, but not always.

>
> Furthermore, the CR1 archtype fails on recent versions of maven because it
> "exploits" a maven assembly bug which allows an empty or missing
> assemblyId.

What is an "assemblyId"?

> Setting the assemblyId in /src/main/assembly/mod.xml to mod
> would fix this.
> http://jira.codehaus.org/browse/MASSEMBLY-464
> http://jira.codehaus.org/browse/MASSEMBLY-517
>
> On Thursday, June 20, 2013 8:38:01 PM UTC-4, ramki wrote:
>> Can you elaborate a bit more on classifier?
>>
>> The module packaging we have in vert.x is kind of unique given to its
>> polyglot nature. We use maven to build the modules the way module has been
>> designed instead of other way around.
>>
>> -ramki
>>

>> On 21-Jun-2013, at 3:12 AM, "johnp...@gmail.com <javascript:>" <

>> johnp...@gmail.com <javascript:>> wrote:
>>
>> I don't consider myself a maven fanatic, but I find it awkard the way CR1
>> forces the vertx module (.zip) as the primary artifact for a project. Maven
>> projects do not allow a packaging type of zip. This seems like a perfect
>> candidate for using a classifier on the vertx module artifact. The vertx
>> module would be a secondary artifact similar to sources and javadoc, and
>> the project could be packaged as a jar or pom as desired.
>>
>> The source change in vertx-platform is rather trivial, though the maven
>> archtype and the gradle scripts for each module needs to updated as well.
>>
>> I've tested the resolution change locally with success, but this requires
>> a large number of module changes so I'd like to see if there are any
>> objections to using a classifier during maven resolution?
>>
>> -------
>> As this is my first post here, I want to thank Tim Fox and other
>> contributors for all their hard work. 2.0 is a major improvement over 1.3.1
>> and I am very excited to see this running in our production enviroment with
>> the new netty framework.
>>
>>
>>
>>
>>
>> --
>> 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 <javascript:>.

[John Meyer]

For better or worse, Maven doesn't allow the primary artifact to be a zip file. A fairly common mistake is to set the packaging type to zip, which results in a "unknown packaging: zip" error. I know Maven 3 is considering a more extensible packaging scheme, specifically for this use case. In the mean time, forcing the project to have a primary artifact of zip can cause unexpected results as more and newer plugins are used. It also causes issues with indexing the project on some repository software since there is a conflict between the canonical name of the jar and the canonical name of the zip.

The immediate issue is that projects generated with the CR1 vertx-maven archtype fail on newer versions of the maven-assembly-plugin with "Assembly: null is not configured correctly: Assembly ID must be present and non-empty." Since version 2.2, the assembly/mod.xml must contain an <id> tag that differentiates the assembly from the primary artifact and other assemblies. By default, this id is used as the classifier for the artifact when deploying to a repository.

There are several solutions to the archtype issue:

1) Mandate version 2.1 of the maven-assembly-plugin.

2) Use a later version of the plugin (2.4 is the most recent), and set the appendAssemblyId to false in the plugin configuration.

3) Decide on a fixed classifier to use for the vertx module artifact, and use the classifier when creating and resolving the vertx module.

Solution 1 is the most limiting, but admittedly requires the smallest source change.

Solution 2 is provided by the plugin for backwards compatibility with projects that require an invalid project setup due to the pre-existing behavior. It does not prevent future conflicts with other plugins or fix the repository indexing issues.

Solution 3 is the most robust and follows "the maven way." Since the maven resolution is a new feature to vert.x 2.0 and this works around the underlying issue of maven not supporting a packaging type of zip, I think this is the best approach.

--
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/a4Jafa3TyEQ/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to vertx+unsubscribe@googlegroups.com.

[Tim Fox]

On 21/06/13 15:45, John Meyer wrote:
> For better or worse, Maven doesn't allow the primary artifact to be a zip
> file.

What does this mean in practice? Do we have to push a jar?

For many modules there will be no .jar

>>> http://repo2.maven.org/maven2/**io/vertx/mod-web-server/2.0.0-**CR1/<http://repo2.maven.org/maven2/io/vertx/mod-web-server/2.0.0-CR1/>
>>>
>>>
>>> mod-web-server-2.0.0-CR1-**javadoc.jar 14-Jun-2013 15:19
>>> 42166
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**sources.jar 14-Jun-2013 15:19
>>> 5881
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**sources.jar.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**sources.jar.sha1 14-Jun-2013 15:19

>>> 40
>>> mod-web-server-2.0.0-CR1.jar 14-Jun-2013 15:19
>>> 8813

>>> mod-web-server-2.0.0-CR1.jar.**asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1.jar.**asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.jar.**asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1.jar.**md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.jar.**sha1 14-Jun-2013 15:19

>>> 40
>>> mod-web-server-2.0.0-CR1.pom 14-Jun-2013 15:19
>>> 1465

>>> mod-web-server-2.0.0-CR1.pom.**asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1.pom.**asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.pom.**asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1.pom.**md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.pom.**sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-mod.**zip 14-Jun-2013 15:19
>>> 8574
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-mod.**zip.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-mod.**zip.sha1 14-Jun-2013 15:19

>>> 40
>>>
>>>
>>> A maven classifier is an optional 5th element of an artifact name. The
>>> maven view of things is that the project's output is still a jar, and if
>>> we
>>> want attach a secondary artifact of zip, we can do that using the
>>> classifier mechanism. Having a zip file with the same "name" as the jar
>>> interferes with server indexing and possibly building more complex
>>> projects.
>>>
>> For Vert.x modules, the main artifact is a .zip, and there might
>> (optionally) be a .jar there too, but not always.
>>
>>
>>
>>> Furthermore, the CR1 archtype fails on recent versions of maven because it
>>> "exploits" a maven assembly bug which allows an empty or missing
>>> assemblyId.
>>>
>> What is an "assemblyId"?
>>
>>> Setting the assemblyId in /src/main/assembly/mod.xml to mod
>>> would fix this.

>>> http://jira.codehaus.org/**browse/MASSEMBLY-464<http://jira.codehaus.org/browse/MASSEMBLY-464>
>>> http://jira.codehaus.org/**browse/MASSEMBLY-517<http://jira.codehaus.org/browse/MASSEMBLY-517>

>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .

>>>>
>>>>
>>>>
>> --
>> 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/a4Jafa3TyEQ/**unsubscribe<https://groups.google.com/d/topic/vertx/a4Jafa3TyEQ/unsubscribe>
>> .

>> To unsubscribe from this group and all of its topics, send an email to

>> vertx+unsubscribe@**googlegroups.com<vertx%2Bunsu...@googlegroups.com>
>> .
>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>

[John Meyer]

No, one can set the packaging type to pom for projects that do not produce a jar. I will setup a project that does this and post it on github.

vertx+unsubscribe@**googlegroups.com<vertx%2Bunsubscribe@googlegroups.com>

.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.

--
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/a4Jafa3TyEQ/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to vertx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Eric Kimn]

If I am reading it right I think he's saying that he wishes vertx would deploy modules in the same way an app server such as jboss or jetty would deploy a war or jar, Since there is no convenient way to make maven create the requisite zip files this post utilizes the maven assembler to post package a zip file that can be then put into the mods directory for vertx to pick up.

http://perfectworldprogramming.com/configuring-maven-to-build-your-vertx-module/

[John Meyer]

Hi Ramki, Tim,

I've made the proposed changes under my personal github account - jpmeyer.

The projects are:

https://github.com/jpmeyer/vert.x.git

https://github.com/jpmeyer/vertx-maven.git

https://github.com/jpmeyer/vertx-gradle-template.git

https://github.com/jpmeyer/mod-lang-rhino.git (Needed for vert.x tests)

The sample projects are:

https://github.com/jpmeyer/vertx-gradle-rhino-module.git

https://github.com/jpmeyer/vertx-maven-rhino-module.git

https://github.com/jpmeyer/vertx-gradle-java-module.git

https://github.com/jpmeyer/vertx-maven-java-module.git

If these are valid, I can issue a Pull Request, or feel free to cherry pick.

Not that all other existing CR1 modules will need to be updated to include the classifier 'mod' line in their gradle scripts too.

 

On Sat, Jun 22, 2013 at 2:30 AM, Eric Kimn <eric...@gmail.com> wrote:

If I am reading it right I think he's saying that he wishes vertx would deploy modules in the same way an app server such as jboss or jetty would deploy a war or jar,  Since there is no convenient way to make maven create the requisite zip files this post utilizes the maven assembler to post package a zip file that can be then put into the mods directory for vertx to pick up.

http://perfectworldprogramming.com/configuring-maven-to-build-your-vertx-module/

--
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/a4Jafa3TyEQ/unsubscribe.

To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.

[Tim Fox]

I think that post is quite old - the Maven archetype project and Gradle
build now takes care of packaging.

[Tim Fox]

On 21/06/13 15:45, John Meyer wrote:

> For better or worse, Maven doesn't allow the primary artifact to be a zip
> file.

I'm still not getting this - if Maven doesn't allow the primary artifact
to be a zip file and there is no .jar file, then what is the primary
artifact?

>>> http://repo2.maven.org/maven2/**io/vertx/mod-web-server/2.0.0-**CR1/<http://repo2.maven.org/maven2/io/vertx/mod-web-server/2.0.0-CR1/>
>>>
>>>
>>> mod-web-server-2.0.0-CR1-**javadoc.jar 14-Jun-2013 15:19
>>> 42166
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**sources.jar 14-Jun-2013 15:19
>>> 5881
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**sources.jar.md5 14-Jun-2013 15:19
>>> 32

>>> mod-web-server-2.0.0-CR1-**sources.jar.sha1 14-Jun-2013 15:19

>>> 40
>>> mod-web-server-2.0.0-CR1.jar 14-Jun-2013 15:19
>>> 8813

>>> mod-web-server-2.0.0-CR1.jar.**asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1.jar.**asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.jar.**asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1.jar.**md5 14-Jun-2013 15:19
>>> 32

>>> mod-web-server-2.0.0-CR1.jar.**sha1 14-Jun-2013 15:19

>>> 40
>>> mod-web-server-2.0.0-CR1.pom 14-Jun-2013 15:19
>>> 1465

>>> mod-web-server-2.0.0-CR1.pom.**asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1.pom.**asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.pom.**asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1.pom.**md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.pom.**sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-mod.**zip 14-Jun-2013 15:19
>>> 8574
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-mod.**zip.md5 14-Jun-2013 15:19
>>> 32

>>> mod-web-server-2.0.0-CR1-mod.**zip.sha1 14-Jun-2013 15:19

>>> 40
>>>
>>>
>>> A maven classifier is an optional 5th element of an artifact name. The
>>> maven view of things is that the project's output is still a jar, and if
>>> we
>>> want attach a secondary artifact of zip, we can do that using the
>>> classifier mechanism. Having a zip file with the same "name" as the jar
>>> interferes with server indexing and possibly building more complex
>>> projects.
>>>
>> For Vert.x modules, the main artifact is a .zip, and there might
>> (optionally) be a .jar there too, but not always.
>>
>>
>>
>>> Furthermore, the CR1 archtype fails on recent versions of maven because it
>>> "exploits" a maven assembly bug which allows an empty or missing
>>> assemblyId.
>>>
>> What is an "assemblyId"?
>>
>>> Setting the assemblyId in /src/main/assembly/mod.xml to mod
>>> would fix this.

>>> http://jira.codehaus.org/**browse/MASSEMBLY-464<http://jira.codehaus.org/browse/MASSEMBLY-464>
>>> http://jira.codehaus.org/**browse/MASSEMBLY-517<http://jira.codehaus.org/browse/MASSEMBLY-517>

>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .

>>>>
>>>>
>>>>
>> --
>> 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/a4Jafa3TyEQ/**unsubscribe<https://groups.google.com/d/topic/vertx/a4Jafa3TyEQ/unsubscribe>
>> .

>> To unsubscribe from this group and all of its topics, send an email to

>> vertx+unsubscribe@**googlegroups.com<vertx%2Bunsu...@googlegroups.com>
>> .
>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>

[Tim Fox]

On 21/06/13 15:45, John Meyer wrote:

> For better or worse, Maven doesn't allow the primary artifact to be a zip
> file. A fairly common mistake is to set the packaging type to zip, which
> results in a "unknown packaging: zip" error. I know Maven 3 is considering
> a more extensible packaging scheme, specifically for this use case. In the
> mean time, forcing the project to have a primary artifact of zip can cause
> unexpected results as more and newer plugins are used. It also causes
> issues with indexing the project on some repository software since there is
> a conflict between the canonical name of the jar and the canonical name of
> the zip.

Can you be more specific about what these issues are? What software, any
references?

>>> http://repo2.maven.org/maven2/**io/vertx/mod-web-server/2.0.0-**CR1/<http://repo2.maven.org/maven2/io/vertx/mod-web-server/2.0.0-CR1/>
>>>
>>>
>>> mod-web-server-2.0.0-CR1-**javadoc.jar 14-Jun-2013 15:19
>>> 42166
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**javadoc.jar.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**sources.jar 14-Jun-2013 15:19
>>> 5881
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-**sources.jar.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-**sources.jar.md5 14-Jun-2013 15:19
>>> 32

>>> mod-web-server-2.0.0-CR1-**sources.jar.sha1 14-Jun-2013 15:19

>>> 40
>>> mod-web-server-2.0.0-CR1.jar 14-Jun-2013 15:19
>>> 8813

>>> mod-web-server-2.0.0-CR1.jar.**asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1.jar.**asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.jar.**asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1.jar.**md5 14-Jun-2013 15:19
>>> 32

>>> mod-web-server-2.0.0-CR1.jar.**sha1 14-Jun-2013 15:19

>>> 40
>>> mod-web-server-2.0.0-CR1.pom 14-Jun-2013 15:19
>>> 1465

>>> mod-web-server-2.0.0-CR1.pom.**asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1.pom.**asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.pom.**asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1.pom.**md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1.pom.**sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-mod.**zip 14-Jun-2013 15:19
>>> 8574
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc 14-Jun-2013 15:19
>>> 475
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc.md5 14-Jun-2013 15:19
>>> 32
>>> mod-web-server-2.0.0-CR1-mod.**zip.asc.sha1 14-Jun-2013 15:19
>>> 40
>>> mod-web-server-2.0.0-CR1-mod.**zip.md5 14-Jun-2013 15:19
>>> 32

>>> mod-web-server-2.0.0-CR1-mod.**zip.sha1 14-Jun-2013 15:19

>>> 40
>>>
>>>
>>> A maven classifier is an optional 5th element of an artifact name. The
>>> maven view of things is that the project's output is still a jar, and if
>>> we
>>> want attach a secondary artifact of zip, we can do that using the
>>> classifier mechanism. Having a zip file with the same "name" as the jar
>>> interferes with server indexing and possibly building more complex
>>> projects.
>>>
>> For Vert.x modules, the main artifact is a .zip, and there might
>> (optionally) be a .jar there too, but not always.
>>
>>
>>
>>> Furthermore, the CR1 archtype fails on recent versions of maven because it
>>> "exploits" a maven assembly bug which allows an empty or missing
>>> assemblyId.
>>>
>> What is an "assemblyId"?
>>
>>> Setting the assemblyId in /src/main/assembly/mod.xml to mod
>>> would fix this.

>>> http://jira.codehaus.org/**browse/MASSEMBLY-464<http://jira.codehaus.org/browse/MASSEMBLY-464>
>>> http://jira.codehaus.org/**browse/MASSEMBLY-517<http://jira.codehaus.org/browse/MASSEMBLY-517>

>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .

>>>>
>>>>
>>>>
>> --
>> 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/a4Jafa3TyEQ/**unsubscribe<https://groups.google.com/d/topic/vertx/a4Jafa3TyEQ/unsubscribe>
>> .

>> To unsubscribe from this group and all of its topics, send an email to

>> vertx+unsubscribe@**googlegroups.com<vertx%2Bunsu...@googlegroups.com>
>> .
>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>

[Tim Fox]

Can you submit PRs? It's much easier to see diffs that way

[John Meyer]

PRs sent

I'm still not getting this - if Maven doesn't allow the primary artifact to be a zip file and there is no .jar file, then what is the primary artifact?

If there is no jar, then the packaging type is set to pom. This means the pom is the primary artifact in the repository. We still attach the vertx module as a zip file with -mod classifier.

Can you be more specific about what these issues are? What software, any references?

To reproduce the "Assembly: null is not configured correctly: Assembly ID must be present and non-empty.", the default installation of maven on OS X (10.8.4) will fail for archetype CR1 generated projects.

As for the indexing issues in repositories, NEXUS-3158 briefly describes the issue. Also, in Sonatype's Maven manual on the assembly plugin, the last sentence of section 8.4.2 says that the assembly ID is essential and required as it forms one of the coordinates used to look up the artifact.

vertx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
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/a4Jafa3TyEQ/unsubscribe.

To unsubscribe from this group and all of its topics, send an email to vertx+unsubscribe@googlegroups.com.

[Tim Fox]

On 23/06/13 18:04, John Meyer wrote:
> PRs sent
>
> I'm still not getting this - if Maven doesn't allow the primary artifact to
>> be a zip file and there is no .jar file, then what is the primary artifact?
>
> If there is no jar, then the packaging type is set to pom. This means the
> pom is the primary artifact in the repository. We still attach the vertx
> module as a zip file with -mod classifier.
>
> Can you be more specific about what these issues are? What software, any
>> references?
>
> To reproduce the "Assembly: null is not configured correctly: Assembly ID
> must be present and non-empty.", the default installation of maven on OS X
> (10.8.4) will fail for archetype CR1 generated projects.

AIUI, that's easily fixed by disabling mandatory assemblyID

>
> As for the indexing issues in repositories,

> NEXUS-3158<https://issues.sonatype.org/browse/NEXUS-3158> briefly
> describes the issue.
Personally I haven't seen any issues with Vert.x artifacts being non
downloadable. Everything seems to work fine.

> Also, in Sonatype's Maven

> manual<http://books.sonatype.com/mvnref-book/reference/assemblies-sect-descriptor.html>on

> the assembly plugin, the
> last sentence of section 8.4.2 says that the assembly ID is essential and
> required as it forms one of the coordinates used to look up the artifact.

Again, I've not seen any reports of clients not being able to look up
Vert.x artifacts.

I'm not saying there isn't a problem, but it all seems rather
theoretical until someone can come up with a concrete important use case
that fails with the current setup.

>
> On Sun, Jun 23, 2013 at 6:11 AM, Tim Fox <timv...@gmail.com> wrote:
>
>> Can you submit PRs? It's much easier to see diffs that way
>>
>>
>> On 22/06/13 21:25, John Meyer wrote:
>>
>>> Hi Ramki, Tim,
>>>
>>> I've made the proposed changes under my personal github account - jpmeyer.
>>>
>>> The projects are:
>>>

>>> https://github.com/jpmeyer/**vert.x.git<https://github.com/jpmeyer/vert.x.git>
>>> https://github.com/jpmeyer/**vertx-maven.git<https://github.com/jpmeyer/vertx-maven.git>
>>> https://github.com/jpmeyer/**vertx-gradle-template.git<https://github.com/jpmeyer/vertx-gradle-template.git>
>>> https://github.com/jpmeyer/**mod-lang-rhino.git<https://github.com/jpmeyer/mod-lang-rhino.git>(Needed for vert.x tests)
>>>
>>> The sample projects are:
>>>
>>> https://github.com/jpmeyer/**vertx-gradle-rhino-module.git<https://github.com/jpmeyer/vertx-gradle-rhino-module.git>
>>> https://github.com/jpmeyer/**vertx-maven-rhino-module.git<https://github.com/jpmeyer/vertx-maven-rhino-module.git>
>>> https://github.com/jpmeyer/**vertx-gradle-java-module.git<https://github.com/jpmeyer/vertx-gradle-java-module.git>
>>> https://github.com/jpmeyer/**vertx-maven-java-module.git<https://github.com/jpmeyer/vertx-maven-java-module.git>

>>>
>>> If these are valid, I can issue a Pull Request, or feel free to cherry
>>> pick.
>>>
>>> Not that all other existing CR1 modules will need to be updated to include
>>> the classifier 'mod' line in their gradle scripts too.
>>>
>>>
>>>
>>> On Sat, Jun 22, 2013 at 2:30 AM, Eric Kimn <eric...@gmail.com> wrote:
>>>
>>> If I am reading it right I think he's saying that he wishes vertx would
>>>> deploy modules in the same way an app server such as jboss or jetty would
>>>> deploy a war or jar, Since there is no convenient way to make maven
>>>> create
>>>> the requisite zip files this post utilizes the maven assembler to post
>>>> package a zip file that can be then put into the mods directory for vertx
>>>> to pick up.
>>>>
>>>>

>>>> http://**perfectworldprogramming.com/**configuring-maven-to-build-**
>>>> your-vertx-module/<http://perfectworldprogramming.com/configuring-maven-to-build-your-vertx-module/>

>>>>
>>>> --
>>>> 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/a4Jafa3TyEQ/**unsubscribe<https://groups.google.com/d/topic/vertx/a4Jafa3TyEQ/unsubscribe>
>>>> .

>>>> To unsubscribe from this group and all of its topics, send an email to

>>>> vertx+unsubscribe@**googlegroups.com<vertx%2Bunsu...@googlegroups.com>
>>>> .
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .

>>>>
>>>>
>>>>
>>>>
>> --
>> 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/a4Jafa3TyEQ/**unsubscribe<https://groups.google.com/d/topic/vertx/a4Jafa3TyEQ/unsubscribe>
>> .

>> To unsubscribe from this group and all of its topics, send an email to

>> vertx+unsubscribe@**googlegroups.com<vertx%2Bunsu...@googlegroups.com>
>> .
>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>

[Tim Fox]

What I think we should do is support it both with the -mod suffix and without, that way we won't break anything.

So the resolver needs to look for -mod first then if not found, with no suffix.

The gradle template and maven archetype can be updated to create modules with the -mod suffix.

John - can you please sign the Eclipse CLA? Then I can pull in your template and archetype changes

>>>> vertx+unsubscribe@**googlegroups.com<vertx%2Bunsubscribe@googlegroups.com>

>>>> .
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>>>
>> --
>> 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/a4Jafa3TyEQ/**unsubscribe<https://groups.google.com/d/topic/vertx/a4Jafa3TyEQ/unsubscribe>
>> .
>> To unsubscribe from this group and all of its topics, send an email to

>> vertx+unsubscribe@**googlegroups.com<vertx%2Bunsubscribe@googlegroups.com>