[infinispan-dev] Syncing to central

Galder Zamarreño galder at redhat.com
Mon Oct 24 05:46:42 EDT 2011


On Oct 20, 2011, at 7:24 PM, Sanne Grinovero wrote:

> On 20 October 2011 18:01, Pete Muir <pmuir at redhat.com> wrote:
>> On 20 Oct 2011, at 17:57, Pete Muir wrote:
>>> On 20 Oct 2011, at 17:52, Sanne Grinovero wrote:
>>> 
>>>> right, sounds a reasonable requirement. Any suggestion to automate this check?
>>> 
>>> Use regexp and parse the transformed-for-release (i.e. with their own versions swapped out) for SNAPSHOT? That's what I've used before and it works.
>> 
>> Actually a better approach is:
>> 
>> 1) Make sure snapshot repos are explicitly disabled on release (this is good practice)
> 
> +1, it should be easy to have a settings.xml around for Infinispan
> releases. Actually assuming the security tokens can be externalized
> this could be committed with the release scripts.
> 
>> 2) Run the build against an empty maven repo (this is good practice as it ensures the build is reproducible without your local junk). To do this use -Dmaven.repo.local=/some/tmp/path
>> 
>> This will then ensure we don't have any snapshots at all in the build.
> 
> Right, and could be included in the custom settings.xml as well.
> Or just use:
>   mvn dependency:purge-local-repository

Don't really wanna purge my local repo unless I have a very good reason to do it cos it'd take forever to recreate.

Using an alternative -Dmaven.repo.local=/some/tmp/path when you're releasing sounds like a much more sane option.

> 
> But I don't trust that as much as the empty repository ;)
> 
>> BTW the eventual goal is to be able to have POMs that don't reference any repositories at all. However the Maven guys are willing to overlook this whilst we get more stuff sync'd to central. So if we do this, it's critically important that we don't add any repositories to POMs. Anything must be proxied through JBoss.org.
> 
> I can't find any <repository> element left? We've been fighting this
> for some time already.
> 
>> We should also do a proper dependency analysis at some point.
> 
> The only weirdness I see is the org.rhq.helpers stuff. It's mostly
> flagged optional or provided but it's a lie, it's required and depends
> on lots of pointless stuff (like Hibernate 3 ??).

There's two aspects to this:

1. We hijack javadoc processing to generate the RHQ xml file, which means that the annotations need be available beyond the compile phase. This forces the annotation, and rhq annotations, dependencies to be required. At the time of writing this, I wasn't aware of annotation processors and that would have been the right way to solve this issue. That should avoid dependencies going beyond compilation time, but would bring other issues, i.e. annotation processor discovery (we'd need one for JBoss Logging and one for this)…etc.

2. RHQ dependencies themselves which are rather dubious.


> For the rest, I'm monitoring it regularly but some help on it is always welcome.
> 
>> I'm also trying to find out if we can get artifact level filters applied, so we can exclude stuff like jclouds (as it pulls in so much stuff) and focus on syncing core etc. for now.
> 
> I don't see it importing additional repositories; how is that a problem?
> 
> Sanne
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list