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