[mule-dev] Re: [mule-scm] [mule][25182] branches/mule-3.x/core/pom.xml: MULE-6576: Support creating MuleArtifacts from Message Processors

[Dirk Olmes]

         <dependency>
             <groupId>org.mule.common</groupId>
             <artifactId>mule-common</artifactId>
-            <version>0.0.1-SNAPSHOT</version>
+            <version>0.0.2-SNAPSHOT</version>
         </dependency>

Can't we create proper releases of the mule-common artifact? It's a Maven anti-best-practice to depend on SNAPSHOT artifacts ...

-dirk

[Christopher Mordue]

You're right. It's generally a bad practice. We're using a SNAPSHOT here because mule-common is still updating very often. For the release of 3.4, we'll change it to a specific version of mule-common and shouldn't need to go back to using a snapshot again.

Chris

[Dirk Olmes]

On Wed, Jan 9, 2013 at 1:11 AM, Christopher Mordue <christoph...@mulesoft.com> wrote:

You're right. It's generally a bad practice. We're using a SNAPSHOT here because mule-common is still updating very often. For the release of 3.4, we'll change it to a specific version of mule-common and shouldn't need to go back to using a snapshot again.

Ah, good to hear. But I see Santiago bumping version numbers in the POMs so I assume we'll be releasing another 3.4 milestone soon. At least in my book that counts as a release which should not depend on any SNAPSHOT dependencies ....

-dirk

[Mariano Capurro]

Why cannot we include the commons module inside mule source code?

--
Mariano Capurro
Director of Engineering
MuleSoft
Corrientes 316 Entre Piso
C.A.B.A., Argentina (C1043AAQ)
Tel: +54 11 5353 4494
Mail: mariano...@mulesoft.com 

[Dirk Olmes]

On Wed, Jan 9, 2013 at 2:51 AM, Mariano Capurro <mariano...@mulesoft.com> wrote:

Why cannot we include the commons module inside mule source code?

Excellent question. I asked that before but did not get a good answer. IMHO the code should sit in next to the Mule sources in SVN but could have a different release cycle.

-dirk

[Mariano Capurro]

If no one opposes can we move it there Chris?

[Christopher Mordue]

It is shared between mule and studio and devkit. Studio doesn't currently depend on mule but if we put this in mule, it would. That is why it is its own jar and independent.

[Dirk Olmes]

It is shared between mule and studio and devkit. Studio doesn't currently depend on mule but if we put this in mule, it would. That is why it is its own jar and independent.

The code could still live inside the main source tree in Mule's SVN but go under a different versioning scheme. But that's only a minor issue.

What troubles me more is that we have three projects depending on SNAPSHOT artifacts now. From what I've seen, mule-common doesn't change that often and cutting a release of it should be a fairly cheap, informal activity. So why not switch to release mode for mule-common now?

-dirk

[Christopher Mordue]

We'll switch out of snapshots once the library is has a more stable api (should be this week). It has still had breaking api changes 1 or 2 times/week. The Studio team would be going crazy these past few weeks if they had to wait for mule artifacts to built and published through bamboo every time we needed to update mule-common rather than pulling the latest snapshot of mule-common directly. So it was been really important for development to use snapshots but soon this should no longer be needed.