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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

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

On Tue, Jan 8, 2013 at 3:50 PM, Dirk Olmes <[hidden email]> wrote:

         <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


Reply | Threaded
Open this post in threaded view
|

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

Dirk Olmes
On Wed, Jan 9, 2013 at 1:11 AM, Christopher Mordue <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

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

On Tue, Jan 8, 2013 at 10:50 PM, Dirk Olmes <[hidden email]> wrote:
On Wed, Jan 9, 2013 at 1:11 AM, Christopher Mordue <[hidden email]> 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
Director of Engineering
MuleSoft
Corrientes 316 Entre Piso
C.A.B.A., Argentina (C1043AAQ)
Tel: +54 11 5353 4494
Mail: [hidden email] 
Reply | Threaded
Open this post in threaded view
|

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

Dirk Olmes
On Wed, Jan 9, 2013 at 2:51 AM, Mariano Capurro <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Mariano Capurro
If no one opposes can we move it there Chris?

On Tue, Jan 8, 2013 at 10:55 PM, Dirk Olmes <[hidden email]> wrote:
On Wed, Jan 9, 2013 at 2:51 AM, Mariano Capurro <[hidden email]> 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
Director of Engineering
MuleSoft
Corrientes 316 Entre Piso
C.A.B.A., Argentina (C1043AAQ)
Tel: +54 11 5353 4494
Mail: [hidden email] 
Reply | Threaded
Open this post in threaded view
|

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

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.

On Jan 8, 2013 5:58 PM, "Mariano Capurro" <[hidden email]> wrote:
If no one opposes can we move it there Chris?

On Tue, Jan 8, 2013 at 10:55 PM, Dirk Olmes <[hidden email]> wrote:
On Wed, Jan 9, 2013 at 2:51 AM, Mariano Capurro <[hidden email]> 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
Director of Engineering
MuleSoft
Corrientes 316 Entre Piso
C.A.B.A., Argentina (C1043AAQ)
Tel: <a href="tel:%2B54%2011%205353%204494" value="+541153534494" target="_blank">+54 11 5353 4494
Mail: [hidden email] 
Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

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.

On Jan 8, 2013 6:38 PM, "Dirk Olmes" <[hidden email]> wrote:

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