Getting away from SNAPSHOTS! (Was Re: [jboss-dev] Re: A few more AOP/tmp failures to go)

Andrew Lee Rubinger andrew.rubinger at redhat.com
Fri Feb 13 08:11:45 EST 2009


This is what I meant by "versioned SNAPSHOTs".

You get them automatically from a "mvn deploy":

http://snapshots.jboss.org/maven2/org/jboss/ejb3/jboss-ejb3-plugin/1.0.1-SNAPSHOT/

But then we'd need some hook in MDEPLOY Plugin to resolve SNAPSHOT 
dependencies to some version so we don't bring in non-versioned SNAPs 
transitively.

Another other point to consider is that JBoss IT will delete SNAPSHOTs 
when they get 30 days old to save resources.

S,
ALR

Dimitris Andreadis wrote:
> So you update the users of those components to those particular build 
> versions?
> 
> One of the problems with snapshots currently is that you don't know a 
> particular build which snapshot is using (at least not by looking into 
> the hudson "changes" tab). Plus you have to trigger the build manually, 
> as nothing changes in the project itself.
> 
> Max Rydahl Andersen wrote:
>> Eclipse's recommended versioning scheme allows for this.
>> We use it with great success in jboss tools.
>>
>> x.y.z.qualifier-typetimestamp
>>
>> Nightly builds: hibernatetools-3.0.0.GA-N200902130014-H1427
>> Release builds: hibernatetools-3.0.0.GA-R200902130014-H1427
>>
>> Makes it all perfectly ordered and cutting edge users can go from 
>> nightly updates to the actual GA release auotmatically.
>> Gives long names but I'm fine with that since the order brings more 
>> benefits.
>>
>> /max
>>
>>
>>
>>
>>
>>> Errors like this make me think that maven snapshots are generally a 
>>> bad idea.
>>>
>>> Awhile back someone (DML I think?) suggested using timestamp releases 
>>> instead (i.e. module-1234484452.jar). This would guarantee that a 
>>> given build for a source revision is always reproducible. In addition 
>>> you can actually rollback to a previous timestamp version should 
>>> something go wrong.
>>>
>>> Thoughts?
>>>
>>>
>>> Dimitris Andreadis wrote:
>>>> I've rolledback the change for now.
>>>>  https://jira.jboss.org/jira/browse/JBAS-6496
>>>>  Dimitris Andreadis wrote:
>>>>> Richard needs to fix the build first:
>>>>>
>>>>> _default:compile-classes:
>>>>>     [mkdir] Created dir: 
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/output/classes 
>>>>>     [mkdir] Created dir: 
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/output/gen-src 
>>>>>     [javac] Compiling 47 source files to 
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/output/classes 
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/src/main/org/jboss/wsf/container/jboss50/transport/DynamicEndpointDeploymentAspect.java:29: 
>>>>> package org.jboss.classloading.spi.dependency does not exist
>>>>> import org.jboss.classloading.spi.dependency.ClassLoading;
>>>>>                                              ^
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/src/main/org/jboss/wsf/container/jboss50/transport/DynamicEndpointDeploymentAspect.java:30: 
>>>>> package org.jboss.classloading.spi.dependency does not exist
>>>>> import org.jboss.classloading.spi.dependency.Module;
>>>>>                                              ^
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/src/main/org/jboss/wsf/container/jboss50/deployment/metadata/EJBArchiveMetaDataAdapterEJB21.java:141: 
>>>>> warning: [deprecation] determineJndiName() in 
>>>>> org.jboss.metadata.ejb.jboss.JBossSessionBeanMetaData has been 
>>>>> deprecated
>>>>>          targetBean.setJndiName(jbossSessionBean.determineJndiName());
>>>>>                                                 ^
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/src/main/org/jboss/wsf/container/jboss50/deployment/metadata/EJBArchiveMetaDataAdapterEJB21.java:142: 
>>>>> warning: [deprecation] determineLocalJndiName() in 
>>>>> org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData has been 
>>>>> deprecated
>>>>>          
>>>>> targetBean.setLocalJndiName(jbossBeansMetaData.determineLocalJndiName()); 
>>>>>
>>>>>                                                        ^
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/src/main/org/jboss/wsf/container/jboss50/transport/DynamicEndpointDeploymentAspect.java:90: 
>>>>> cannot find symbol
>>>>> symbol  : class Module
>>>>> location: class 
>>>>> org.jboss.wsf.container.jboss50.transport.DynamicEndpointDeploymentAspect 
>>>>>
>>>>>          mutableAttachments.addAttachment(Module.class, 
>>>>> ClassLoading.getModuleForClassLoader(epLoader));
>>>>>                                           ^
>>>>> /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x/JBossAS_5_0/webservices/src/main/org/jboss/wsf/container/jboss50/transport/DynamicEndpointDeploymentAspect.java:90: 
>>>>> cannot find symbol
>>>>> symbol  : variable ClassLoading
>>>>> location: class 
>>>>> org.jboss.wsf.container.jboss50.transport.DynamicEndpointDeploymentAspect 
>>>>>
>>>>>          mutableAttachments.addAttachment(Module.class, 
>>>>> ClassLoading.getModuleForClassLoader(epLoader));
>>>>>                                                         ^
>>>>> Note: Some input files use unchecked or unsafe operations.
>>>>> Note: Recompile with -Xlint:unchecked for details.
>>>>> 4 errors
>>>>> 2 warnings
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>>
>>
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com



More information about the jboss-development mailing list